Created attachment 23839 [details] Patch to allow binding of external contexts I have created a patch to bind an external context to the JNDI tree using the <Resource /> tags. For example the following Context.xml binds a remote JBoss naming context to the "java:/comp/env/ejb" <Context> <Resource name="ejb" type="javax.naming.Context" factory="org.jnp.interfaces.NamingContextFactory" URL="jnp://apphost:1099/myapp"/> </Context> The reason why I am using this instead of using the <Ejb /> references is twofold: 1) The tomcat naming context stores the retrieved EJB in its context, returning the same object with each lookup() call. FROM JSR 220: NOTE: When a stateful session bean is looked up or otherwise obtained through the explicit JNDI lookup mechanisms, the container must provide a new stateful session bean instance, as required by the Java EE specification (Section “Java Naming and Directory Interface (JNDI) Naming Context” [12]). 2) After trying a quick hack to fix (1), I realised that each call it was creating a fresh NamingContext and associated objects for each call. Which is an unnecessary given that it should be essentially static. ************ THE PATCH ************ NamingContextListener -- looks up the resource and rebinds (so it is stored as type=NamingEntry.CONTEXT). NamingContext -- I needed to wack a toString() call in as JBoss's JNP starting complaining that it wasn't a CompoundName because tomcat uses CompositeName. Not the best solution but it works.
I think it would be better to address the root cause of this issue, that Tomcat was returning the same object from a JNDI lookup rather than a new one. That issue was reported (and fixed) as bug 49994. However, that in turn caused big problems (bug 50159) for JNDI DataSources where apps expect the same connection pool to be used for each lookup. Tomcat 7 has addressed this by introducing the singleton attribute for resources. There are no plans to back-port the singleton feature to Tomcat 6 but if it is required please re-open bug 50159 and request a back-port to Tomcat 6. I am closing this as won't fix since it addresses the symptom rather than the root casue.