-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: challenges and gotchas, using multiple JNDI implementations.
PostPosted: Thu Oct 22, 2009 3:42 pm 
Newbie

Joined: Thu Sep 17, 2009 10:02 pm
Posts: 4
I thought I would share this with the group, in case you are ever in a position of having to use multiple JNDI implementations because you are using multiple application servers. We have a packaged application called @task which has to run on JBoss, however we decided to use glassfish for our custom web applications, because of the superior, free support.

We were getting that oddball class loader error for org.jnp.interfaces.namingcontext on apps that used JTA and JDBC datasources for hirenate or JPA even though I wasn't using that class in any of my code.This class was also showing up in my error message when I neglected to put the connector in my default domain /lib/ext folder.

JNDI is used to provide a unified scheme to bind names to objects across platforms. check here for details: http://java.sun.com/products/jndi/

Normally you can access the JNDI default implementation in an appserver by simply creating a new initial context with a constructor with an empty argument list like so:
new InitialContext()

However, we have to set the properties for the initial context when we access the EJBs in the @task application which runs under JBoss to use the JBoss implementation of JNDI, which is the class referred to above, along with the JBoss JNDI URL. Apparently when you set those init context properties in a piece of code and that code is executed, those properties become the default, at least under glassfish. Therefore when you call an initial context to access JNDI in glassfish you have to reset the properties as follows
props = new Properties();
props.setProperty("java.naming.factory.initial", "com.sun.appserv.naming.S1ASCtxFactory");
props.setProperty("java.naming.provider.url", "iiop://127.0.0.1:3700");
and create the initial context like so:
new InitialContext(props)

Furthermore, if you need to use datasources and connection pools, you need to account for this in your persistence layer, because JNDI is how the datasource is located by name. In Hibernate that means that for a situation where you are using multiple implementations of JNDI, the optional JNDI parameters become mandatory, and should be set like so:

<property name="hibernate.jndi.class">com.sun.appserv.naming.S1ASCtxFactory</property>
<property name="hibernate.jndi.url">iiop://127.0.0.1:3700</property>


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.