A well configured client for a standalone application will show errors if the destination server will be / or change to a clustered environment.

Example log entry:
ERROR - JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
INFO - Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='node1', clientMappings=[ClientMapping

{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',destinationPort=4447}

], resolvedDestination=[Destination address=127.0.0.1, destination port=4447]} in cluster ejb
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed

To avoid this the configuration must have the same properties twice, one for initial connection and one for the cluster.

remote.connection.default.username=user
remote.connection.default.*=
plus:
remote.cluster.ejb.username=user
remote.cluster.ejb.*=

From a client perspective it should make no difference whether a single server or a cluster is the destination.
This might be expected as a behavior known as "Configuration by Exception" or "Convention over Configuration" in JEE5 and JEE6.
Also this is the expected behavior if the client migrate from former AS versions.

Suppose that all member in a cluster use the same configuration, credentials and applications (otherwise it might end in a configuration/administration hell) the client should assume that a returned cluster member list can be accessed with the same configuration as the initial node.
This is, more or less, reflected by the example configuration above, because there is a possiblity to configure each initial node different, but if the cluster view is received all nodes will become the same configuration which can be end up in confusing error messages.

Also the default configuration must not aware of the cluster name 'ejb' for most of the simple cluster cases.

I see two different approaches:

• the cluster configuration contains only properties specific for cluster communication (no credentials or connection settings)
• the client will use the initial parameter as default as long as the property is not overwritten by cluster configuration