Dynamic host to host access for ejbs

[bjorn.palmqvist]

Hi,

We are trying to migrating some legacy code to JBoss AS 7.1 (running on nightly builds at the moment). We need host to host access but the static way described in https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance is not an option. We like to do this dynamically from the code, more like the extension of EJBClientConfiguration that is described in https://community.jboss.org/message/647202#647202.

The reason for this is that the servers contains a small number of the same beans and if they calls a bean on the wrong server the program may not work (we know that this is bad). That's way we want to have full control of what server is used in the lookup process.

We have tried if that could work, but we later on get a ClassNotFound exception of org.jboss.xnio.Options (and probably all the client stuff as well) if we add those dependensys to the ear then we get a class loader issue when the class with the same version is already loaded.

So is there any way of doing this from code or is the only option to use the static way in the standalone.xml?

[jaikiran]

Björn Palmqvist wrote:

Hi,

We are trying to migrating some legacy code to JBoss AS 7.1 (running on nightly builds at the moment). We need host to host access but the static way described in https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance is not an option. We like to do this dynamically from the code, more like the extension of EJBClientConfiguration that is described in https://community.jboss.org/message/647202#647202.

How dynamic do you want it to be? One option I was thinking was to allow the jboss-ejb-client.xml to include the connection options as an alternative to pointing to a outbound connection in the remoting subsystem. That way at deploy time you can configure the jboss-ejb-client.xml with the necessary configurations and then be able to use it. Note that I haven't fully thought through this but am going to look into this if that allows an easier way to use it in the applications.

[bjorn.palmqvist]

We want to decide before each call wich server we are going to access.

One option could be to programmatically choose with remote endpoint to use in some way when we creating the InitialContext to do the lookup with, with a property or something like that.

Another problem is that the unit test that we have tests that host to host code in a client to host fashion to. I imagine that the host to host way will not work when the unit test running is trying to us it.

So what I'm asking for is a general way of doing this for both client to host and host to host if its possible. If that not possible then maybe a way to detect in with mode we are running at the moment, in that case we can wrap it with a general way of doing it.

[jaikiran]

Björn Palmqvist wrote:

We want to decide before each call wich server we are going to access.

One option could be to programmatically choose with remote endpoint to use in some way when we creating the InitialContext to do the lookup with, with a property or something like that.

You can do that via the JBoss EJB client API programatically. The reason I did not mention it in this thread earlier was because some users did not want to use JBoss specific APIs. If you are willing to use that API, then yes that should allow you to communicate with whichever server you want to, since the connection creation will be left to you. The documentation of that API will be available in time for Final but I can point you to some examples, if you are interested.

[markus78]

I am allso very interested in this!

[jaikiran]

markus78 wrote:

I am allso very interested in this!

Sure. Please add any relevant details on how your application intends to use this. Does the jboss-ejb-client.xml approach I suggested above sound usable for you?

[markus78]

No i need to select a specific server at initialContext , We have been uslng provider_url before but this is not applicable in jboss 7. I have nothing against uslng the client api but I cant get it working in server to server cituation I get the same problems as Bjorn. Perhaps you can create a mini demo showing host to host calls from one server to another where the destination host i declared in runtime uslng the client api. Pretty much the same demo as you did for standalone client to host (which works flawlessly ).  This issue asside , I really like Jboss 7 keep up the great work!

[bjorn.palmqvist]

I have no problem with use of API.

I have actual tested this by using the following code as a template https://github.com/jbossas/jboss-ejb-client/blob/master/src/test/java/org/jboss/ejb/client/test/client/EJBClientAPIUsageTestCase.java, to solve the client to host in a dynamic way (but changed this to use the EJBClientConfiguration way later). But when I tried it host to host it did not work. Complaining on missing dependency. I tried to add those to the ear lib directory but then I get this instead:

   16:13:07,693 ERROR [org.jboss.ejb3.invocation] (pool-9-thread-2) JBAS014134: EJB Invocation failed on component CalculatorBeanSC for method public abstract int org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculatorSC.add(int,int): javax.ejb.EJBException: Unexpected Error

   ...

   Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jboss.ejb.client.remoting.IoFutureHelper.get(Lorg/xnio/IoFuture;JLjava/util/concurrent/TimeUnit;)Ljava/lang/Object;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/as/quickstarts/ejb/remote/stateless/ManuelServiceLocator, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for resolved class, org/jboss/ejb/client/remoting/IoFutureHelper, have different Class objects for the type org/xnio/IoFuture used in the signature

   ...

So an example and which dependencies that are needed is really usefull.

[jaikiran]

Okay, so both markus and you are looking for an example on achieving this. I'll get some documentation/example together for this one.