Pramod Kumar
Pramod Kumar

Reputation: 13

Remote Access to EJB's on JBOSS AS7.1 from JBOSS 5.1

I have an enterprise application delopyed on JBOSS 5.1. It needs to remotely access EJB's deployed on another instance of JBOSS AS 7.0+. Now since AS 7.0+ remote access of EJB protocol has changed and there is a dependency on jboss-client.jar file contents for remote access.

Some of the classes inside jboss-client.jar from 7.0+ have the same structure as the libaries available in 5.1(Ex.: org.jboss.logging.Logger). However both the classes have different set of methods.

Invoking a remote EJB from 5.1 as follows

 final Hashtable jndiProperties = new Hashtable();
 jndiProperties.put(Context.URL_PKG_PREFIXES,"org.jboss.ejb.client.naming");
 context = new InitialContext(jndiProperties);

 final String appName = "my-ear";
 final String moduleName = "my-ejb-1.0";
 final String distinctName = "";
 final String beanName = "ServiceBean";         
 final String viewClassName = "org.test.Service";
// let's do the lookup
 Service service = (Service) context.lookup("ejb:" + appName + "/"
                + moduleName + "/" + distinctName + "/" + beanName + "!"
                + viewClassName + "?stateful");

leads to NoSuchMethodException for org.jboss.logging.Logger.getMessageLogger

This is because JBOSS 5.1 has a library called 'jboss-logging-spi.jar' which contains the exact same class(Logger) as above. hence the JVM tries to invoke getMessageLogger on Logger class defined in 'jboss-logging-spi.jar' instead of 'jboss-client.jar'.

Any ideas on how can i can enforce the JVM to look for the right class(Logger in jboss-client.jar)?

So far I tried this option:

Any ideas on resolving this problem of invoking EJBs remotely hosted on JBOSS 7.0+ from application running on JBOSS 5.1?

Upvotes: 1

Views: 488

Answers (1)

Gabriel Aramburu
Gabriel Aramburu

Reputation: 2981

In order to fix the class version issue, the third option looks to be the right approach.

What I see from the link that you have posted, is that probably you need to add to Classloading element the attribute:

parent-first="false"

parent-first (true/false) - the classloader should load at first everything from your war/ear/jar and then from parent(in case of war/jar within ear it would mean ear, otherwise it's JBossAS)

Additionaly, there is a couple of tools that can be useful when you are dealing with Classloder configuration, enable jboss classloder logging and to use the JMX Console.

I hope this can help.

Upvotes: 0

Related Questions