We want to migrate an old application from Glassfish to TomEE. We encounter a problem about JNDI.
When I run the cmd for Glassfish server asadmin list-jndi-entries I get some JNDI entries:
java:global: com.sun.enterprise.naming.impl.TransientContext
UserTransaction: com.sun.enterprise.transaction.TransactionNamingProxy$UserTransactionProxy
com: com.sun.enterprise.naming.impl.TransientContext
OURAPPSERVER-Q2: com.ourcompany.product.OurAppServer
com.sun.enterprise.container.common.spi.util.InjectionManager: com.sun.enterprise.container.common.impl.util.InjectionManagerImpl
ejb: com.sun.enterprise.naming.impl.TransientContext
jdbc: com.sun.enterprise.naming.impl.TransientContext
AppServer: com.sun.enterprise.naming.impl.TransientContext
As you can see, there is AppServer JNDI entry. This entry is bind from our code manually.
try {
InitialContext context = new InitialContext();
context.rebind("AppServer/facede", this);
} catch (NamingException e) {
e.printStackTrace();
logger.severe("Unable to register the service facade bean, "
+ "JPOS will not be able to access services");
}
This code is not working in TomEE. I get some error like:
javax.naming.NameNotFoundException: Name [AppServer/facede] is not bound in this Context. Unable to find [AppServer].
at org.apache.naming.NamingContext.bind(NamingContext.java:899)
at org.apache.naming.NamingContext.rebind(NamingContext.java:225)
It seems like the container can't found context base on AppServer.
I am not a master of JNDI. Then I have checked some documents. The java:comp/env/ is the basic namespace. And "jdbc" for DBCTM DataSource references, "jms" for JMS connection factories, "mail" for JavaMail connection factories, "url" for URL connection factories.
We don't want to change too much on our old application code. It's not use any special features of Glassfish. I want to know how to define a JNDI in a correct way.
Is there anyone could tell me why Glassfish can use AppServer as namespace, but TomEE can't.
Tomcat (then TomEE) is not designed to change JNDI at runtime like it. Saying it simply the best is to not use this pattern but a contextual resource. Inject the resource you desire and that's this resource you change instead of JNDI (which is quite more impacting that it seems)