jboss-client.jar really needed for Tomcat?

[henk53]

Hi,

Sorry for this question which is probably extremely basic, but I'm just trying to understand what's going on under the hood.

I have a servlet running inside a standalone Tomcat 6.0.14 instance. From this servlet I would like to connect to a Jboss 4.2 EJB container to either send a message to a JMS topic, or to retrieve an EJB bean.

Since Tomcat already provides a JNDI implementation, I wonder whether I -have- to include the jbossall-client.jar in order to obtain a directory connection to Jboss from Tomcat, or whether I can somehow configure something so that new javax.naming.InitialContext(...); transparently resolves to the directory service operated by Jboss.

The catch is of course to do this without including jbossall-client.jar to the web application running on Tomcat.

Would this be possible?

[henk53]

Anyone cares to comment on this?

[henk53]

I wonder why nobody from Jboss answers this question. Should I rephrase the question in any way?

Or is it something simply nobody, even at Jboss, knows?

[kahzoo]

I'm not from JBoss/RedHad, but my guess is YES, you need the client jars from JBoss to access JBoss JNDI tree from a standalone Tomcat.

The reason is, although the JNDI application programming interface is publicly defined by J2EE spec, the underlying communication protocol (between the JNDI server and client) is vendor specific, and if you need to connect to JBoss's JNDI sever, you need JNDI client classes which understand/talk the JBoss JNDI protocol.

I believe the minimum set of jars you need to access JBoss JNDI is:

jboss-common-client.jar
jnp-client.jar

But if you need to access other components like EJB, MQ, etc, you will also need other jars, and going with jbossall-client.jar would probably be the safest way to avoid ClassNotFoundException.

Hope this helps.

[henk53]

"kahzoo" wrote:

The reason is, although the JNDI application programming interface is publicly defined by J2EE spec, the underlying communication protocol (between the JNDI server and client) is vendor specific, and if you need to connect to JBoss's JNDI sever, you need JNDI client classes which understand/talk the JBoss JNDI protocol.
[...]
Hope this helps.

It sure does, thanks a lot! :-)

I do wonder, but perhaps this is not a question for this forum, why a JNDI connection to the Jboss AS directory can't be made without exposing the jboss-client-jar to the client application. I mean, it's also possible to provide authentication services to a Java EE application, without the application itself having to know about a particular authenticator. I.e. in Tomcat these are called realms and are defined at the servlet container level, not at the application level.

The reason I'm asking is that I'm building an application where the dependencies should be as few as is reasonably possible. As much as possible should be defined at the servlet or AS level.

[jaikiran]

"henk53" wrote:

I do wonder, but perhaps this is not a question for this forum, why a JNDI connection to the Jboss AS directory can't be made without exposing the jboss-client-jar to the client application.

The reason I'm asking is that I'm building an application where the dependencies should be as few as is reasonably possible. As much as possible should be defined at the servlet or AS level.

Remember that JNDI (similar to JDBC) is just a set of interfaces. There are various JNDI service providers. Tomcat has its own JNDI service and JBoss has its own. So when a client in Tomcat wants to use JBoss JNDI service, the client has to pass the appropriate properties (similar to what you do with JDBC DriverManager to load the appropriate drivers). The properties are usually passed through a jndi.properties file or through the constructor of the InitialContext class. Here's an example:

Properties props = new Properties();
 props.put(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
 props.put(Context.PROVIDER_URL,"jnp://localhost:1099");

 Context ctx = new InitialContext(props);

As a result, you will have to package the required jar files (again, similar to your JDBC driver jars) with the client. Kazuhisa is right, you can package the jbossall-client.jar with the client to access the JNDI service of JBoss.