Please don't misunderstand me, I think its a great feature, that I don't have to write code on the client side to define where a remote bean is deployed. I only think that it would be nice if I have the possibility to control this routing a little bit.

I think I found a solution with the current implementation: As mentioned above, I have to write my own selector to make the endpoint definition more dynamic. This selector is responsible for adding receiver to the EJBClientContext. When I write my own receiver I can influence the way how an endpoint is found. Now I can use the distinct name part of the JNDI lookup path only on the client side. I don't have to set it at deploy time. I can use a special prefix to seperate it from distinct names which were used at deploy time. This part can define a cluster or node. My receivers use it to match against the corresponding endpoint. And I don't need it in the JNDI path on the server.

My question to the JBoss developers is, is this a way to go? Will this work with the JBossAS 7.1 final release or do I use an API which is a subject to change?

Ask yourself: Why do I need the control over the host to be contacted if I can get that automatically?

Say you have the same app deployed on N hosts. The same version. Each host serves different customer with its own database, configurations and so on. The app has admin service EJB.

Now there is an admin console which calls the admin EJB on all N hosts. It lets the admin to control the apps for all customers from one screen. Admin needs to know on which host he is operating on. List of hosts is dynamic and comes from admin console database. Admin console needs to call the same app, same release, same EJB running on different hosts, and needs to know the host.

Also in a multi-tenant cloud environment, I'd rather have the tenant-id as a qualifier than configure all of the wiring by hand, which is error prone and simply not feasible in huge installations. Both client and server already have that id (and can't tamper with it), so it would be great, if all the wiring would then work automatically, too!

Admin needs to know on which host he is operating on. List of hosts is dynamic and comes from admin console database. Admin console needs to call the same app, same release, same EJB running on different hosts, and needs to know the host.

Sorry Sergey, if I'm missing something you are trying to explain here, but if I understand it correctly, I think what you want to do here is still possible with currently available API. Once you have list of all hosts & corresponding ports (which is coming from Admin console DB), you can create a selector for each host:port pair & set that selector just before you lookup/call your admin service EJB. Something like below:

//Create selector for serverA

EJBClientContext.setSelector(SelectorA);

ctx = new InitialContext(props);

ctx.lookup(bean_on_serverA);

//Create selector for serverB

SelectorA = EJBClientContext.setSelector(SelectorB); // when you set SelectorB, this call will return previously set selector, if any, which in this case will be SelectorA

Admin needs to know on which host he is operating on. List of hosts is dynamic and comes from admin console database. Admin console needs to call the same app, same release, same EJB running on different hosts, and needs to know the host.

Sorry Sergey, if I'm missing something you are trying to explain here, but if I understand it correctly, I think what you want to do here is still possible with currently available API. Once you have list of all hosts & corresponding ports (which is coming from Admin console DB), you can create a selector for each host:port pair & set that selector just before you lookup/call your admin service EJB. Something like below:

//Create selector for serverA

EJBClientContext.setSelector(SelectorA);

ctx = new InitialContext(props);

ctx.lookup(bean_on_serverA);

//Create selector for serverB

SelectorA = EJBClientContext.setSelector(SelectorB); // when you set SelectorB, this call will return previously set selector, if any, which in this case will be SelectorA

ctx.lookup(bean_on_serverB);

// if needed set SelectorA back

SelectorB = EJBClientContext.setSelector(SelectorA);

//do the stuff with SelectorA

I don't think that this will work as expected. The selector is a static field of the EJBClientContext. The selector is shared by all calls to all JBoss server. Your sollution will only work when there are no calls to other beans at the same time.

I don't think that this will work as expected. The selector is a static field of the EJBClientContext. The selector is shared by all calls to all JBoss server. Your sollution will only work when there are no calls to other beans at the same time.

Sorry, I forgot to mention, assuming that each selector connects to only a specific server (host/port). I agree, this will work only for only 1 server at a time & all the beans deployed on that very same server, so for your mentioned use case Bernd, this will not work. But if I understand correctly Sergey's use case everytime he wants to access different server(say on server B), he'll need to replace existing selector(selector for server A) with the corresponding server selector(for server B) just before looking-up/calling . And yes, using this approach, only beans on connected server (say server B) will be accessible.

I am not saying it is impossible with JBoss 7 implementation. It just looks cumbersome to me.

I have to use proprietary JBoss API.

If selector is static, as pointed out above. I would need to synchronize at the application level. Say I have two people working with admin console at the same time. Two threads are building the pages by querying remote hosts ...

If selector is static, as pointed out above. I would need to synchronize at the application level. Say I have two people working with admin console at the same time. Two threads are building the pages by querying remote hosts ...

Do you mean you have more than one admin console(s) (which I assume is remote standalone java client) running in same JVM at the same time?

I'm not sure, but I'd assume that the selector is not used when you do the lookup, but when you do the call! So that approach won't work at all!

Yes, thats right. The remoting things and the EJBClientContext is used when a beans business method is called. I asumed that in the above example the calls to the proxy were made in between. Doing the calls all together at the end of the example will not work.

Note that all my answers in this reply will be in context of a remote client which does not run within a AS7 instance.

Bernd Koecke wrote:

I think I found a solution with the current implementation: As mentioned above, I have to write my own selector to make the endpoint definition more dynamic. This selector is responsible for adding receiver to the EJBClientContext.

Yes, that's correct. The selector is what has the power to decide what the EJBClientContext looks like. The EJBClientContext in-turn has a collection of receivers for different nodes which will be used for the invocations. It's ultimately upto the selector to decide/implement the logic for creating and maintaining the EJBClientContext and adding/removing receivers from that EJBClientContext. By default, we provide a selector which is based on picking up node configurations from a properties file. But you can plugin your own implementation to use a different selector.

Bernd Koecke wrote:

Now I can use the distinct name part of the JNDI lookup path only on the client side. I don't have to set it at deploy time. I can use a special prefix to seperate it from distinct names which were used at deploy time. This part can define a cluster or node. My receivers use it to match against the corresponding endpoint. And I don't need it in the JNDI path on the server.

I read your previous reply related to this which tried to explain your usecase, but I could not understand it completely. Are you saying that your EJBClientContext has (for example) 5 nodes which have the same application (identified by the combination of app/module/bean name) deployed and you want to specifically select one of the 5 nodes? And you don't want to use the distinct name to do that? Let's keep out clustering from this because that's a different case which needs more explanation.

Bernd Koecke wrote:

My question to the JBoss developers is, is this a way to go? Will this work with the JBossAS 7.1 final release or do I use an API which is a subject to change?

Yes, you are understanding the API right. The next version of the API is targetted to be CR1 so there won't be huge changes to the API.

I'm not sure, but I'd assume that the selector is not used when you do the lookup, but when you do the call! So that approach won't work at all!

Yes, thats right. The remoting things and the EJBClientContext is used when a beans business method is called. I asumed that in the above example the calls to the proxy were made in between. Doing the calls all together at the end of the example will not work.

The EJBClientContext (from a selector) is used only when a server side communication has to be done. For stateless beans we don't have to connect to the server unless there's a invocation on the (proxy of the) bean. However, for stateful beans we do connect to the server (and effectively use the EJBClientContext) during lookup because we have to create a session (for that client) for the stateful beans.