At various places in EJB client to server processing, the method

EJBClientContext.performLocatedAction(EJBLocator, LocatedAction) 

is called to choose a target server to send the invocation to, from among all those known to the client.

This choice of target server depends on the wildfly-discovery mechanism, which in turn depends on the registration various services (e.g. a service representing a deployed module, an available node, or a cluster of nodes) needed to satisfy the invocation. These services are represented as ServiceURLs and contain two types of discovery related information:

• attributes (module=, node=, cluster=) used to identify the services they represent, and
• concreteURIs representing the location of those services

These concreteURIs can generally will point to destinations over which a connection can be established by a transport provider, such as

ejb.jboss:remoting+http://hostname:port;cluster=clustername

However, they may also have location-related information embedded into their scheme, such as:

ejb.jboss:node:nodename;cluster=clustername

Here, the ServiceURL has a concrete URI of node:nodename which, rather than being a URI which could be used to connect to a remote host (like remoting+http://hostname:port) rather indicates that the cluster clustername has an abstract node called nodename associated with it. Other possibilities for such abstract scheme information include "local" and "cluster". When performLocatedAction encounters such a ServiceURL, it will perform a subsequent lookup to resolve the abstract node to a concreteURL which can be used to create a connection.

The operation of performLocatedAction depends in a large part on the existence of these ServiceURLs containing concreteURIs which have such information embedded in their schemes.

This issue concerns the fact that such ServiceURLs, although code for their processing exists in performLocatedAction, they are not being created and registered at present and so performLocatedAction is not functioning as intended.