jboss-3.2.1_tomcat-4.1.24 Servlet to Local Session EJB acces

[rcostanzo]

Hi all,

I have an application in an EAR which has been working without issue for me on the default distribution of Jboss 3.2.1 with Jetty. I'm trying to switch over to Tomcat using the bundled jboss 3.2.1 / Tomcat 4.1.24 distribution. However, my EAR which works fine with Jetty is getting the following error with Tomcat when looking up a Stateless Session EJB's Local Home from a servlet:

[java] javax.naming.CommunicationException: Receive timed out. Root exception is
[java] java.net.SocketTimeoutException: Receive timed out
[java] at java.net.PlainDatagramSocketImpl.receive(Native Method)
[java] at java.net.DatagramSocket.receive(DatagramSocket.java:680)
[java] at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1038
)
[java] at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1158)
[java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:478)
etc....


My EAR is packaged as follows:
MyEAR.ear
MyWebApp.war
-- Contains servlet classes
MyEJBs.jar
-- Contains all Session EJB Facade classes
-- Contains all Session EJB interfaces


Note that I have unit tests which access the EJBs directly from a remote JVM using the remotes and they all run fine.

The code I use to do the actual lookup to the session EJBs from the facade is XDoclet generated:

InitialContext initialContext = new InitialContext();
cachedLocalHome = (mts.psp.ui.SessionManagerLocalHome) initialContext.lookup(local/mts.psp.ui.SessionManager);

Note that I'm using the physical JNDI name and not the logical java:comp/env/ejb/... one.

Is there something I'm missing to get Tomcat to access an EJB local home? I'm not using any of the ejb-ref-local or ejb-ref tags in the web.xml and jboss-web.xml, but that wasn't necessary for Jetty. What strikes me is the fact that the exception is for a socket timeout, which if it's using a local EJB should there really be any sockets being opened?

Any insight into this issue would be greatly appreciated.

[jonlee]

I don't think the issue involves the interface. It looks like it just involves the lookup. That you can perform a remote lookup means that it is operating on port 1099 (I would imagine) although this wouldn't be a factor for standard internal lookups usually.

I would check the server/instance/conf/jndi.properties and see that this doesn't enable an over-the-wire lookup by specifying the JNDI URL. Also check that you don't have any other jndi.properties files floating around that could affect your system. If this is ok, I would add some Java debug lines to find out if java.naming.provider.url is defined in your initial context (as inherited from the system) and if it is defined, determine the value. This should at least help locate the issue. In theory, this should not be set at all. But from your description, it sounds like it is set and it appears to be defined for a non-standard port.

So no concrete help here. Just some suggestions as to what to look for.

[rcostanzo]

Thanks for the reply. Unfortunately it does not look like the provider url is being set. I double checked my jndi.properties and that line is still commented out. The only properties in my context are the two other lines in the jndi.properties:

[java] KEY IS: java.naming.factory.initial
[java] VALUE IS: org.jnp.interfaces.NamingContextFactory
[java] KEY IS: java.naming.factory.url.pkgs
[java] VALUE IS: org.jboss.naming:org.jnp.interfaces:org.jboss.naming:org.jnp.interfaces

[rcostanzo]

It looks like the issue may be related to classloading (shot in the dark there). The issue is that the org.jnp.interfaces.NamingContext which has its local server Naming object set when the jnpserver is created on statup is coming back as null when accessing the NamingContext from a request started in Tomcat (i.e. servlet doing a local home lookup). Because this is null, JBoss then sends out a broadcast looking for another server, and that is what is timing out.

I printed out all of the classloader info I could get using the nice debug util included in the jboss examples. When not accessing EJBs through Tomcat the NamingContext class's loader details looks like:


[java] org.jnp.interfaces.NamingContext(10bbf9e).ClassLoader=org.jboss.mx.loading.Unif
iedClassLoader3@12611a7{ url=file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/
server/default/conf/jboss-service.xml/1.jboss-service.xml ,addedOrder=2}
[java] ..org.jboss.mx.loading.UnifiedClassLoader3@12611a7{ url=file:/C:/jboss-3.2.1_to
mcat-4.1.24/server/default/tmp/deploy/server/default/conf/jboss-service.xml/1.jboss-servic
e.xml ,addedOrder=2}
[java] ..org.jboss.system.server.NoAnnotationURLClassLoader@e53108
[java] ..sun.misc.Launcher$AppClassLoader@12f6684
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/bin/run.jar
[java] ....file:/C:/j2sdk1.4.1_03/lib/tools.jar
[java] ..sun.misc.Launcher$ExtClassLoader@f38798
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/dnsns.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/ldapsec.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/localedata.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/sunjce_provider.jar
[java] ++++CodeSource: (file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/lib/jnpserve
r.jar <no certificates>)
[java] Implemented Interfaces:
[java] ++interface javax.naming.Context(513d61)
[java] ++++ClassLoader: null
[java] ++++Null CodeSource
[java] ++interface java.io.Serializable(19e8329)
[java] ++++ClassLoader: null
[java] ++++Null CodeSource



When accessing it (indirectly) through Tomcat by looking up the local home, it looks like:



[java] org.jnp.interfaces.NamingContext(4e18d4).ClassLoader=WebappClassLoader
[java] available:
[java] Extension[javax.activation, implementationVendor=Sun Microsystems, Inc., implementationVendorId=com.sun, implementationVersion=1.0.2, specificationVendor=Sun Microsystems, Inc., specificationVersion=1.0]
[java] Extension[org.apache.commons.beanutils, implementationVendor=Apache Software Foundation, implementationVersion=1.4-dev, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[org.apache.commons.collections, implementationVendor=Apache Software Foundation, implementationVersion=2.1, specificationVendor=Apache Software Foundation,
specificationVersion=2.1]
[java] Extension[org.apache.commons.digester, implementationVendor=Apache Software Foundation, implementationVersion=1.3, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[org.apache.commons.validator, implementationVendor=Apache Software Foundation, implementationVersion=1.0.1, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[Struts Framework, implementationVendor=Apache Software Foundation, implementationVendorId=org.apache, implementationVersion=1.1, specificationVendor=Apache Software Foundation, specificationVersion=1.1]
[java] delegate: false
[java] repositories:
[java] /WEB-INF/classes/
[java] required:
[java] ----------> Parent Classloader:
[java] java.net.FactoryURLClassLoader@13c6a8b
[java]
[java] ..WebappClassLoader
[java] available:
[java] Extension[javax.activation, implementationVendor=Sun Microsystems, Inc., implementationVendorId=com.sun, implementationVersion=1.0.2, specificationVendor=Sun Microsystems, Inc., specificationVersion=1.0]
[java] Extension[org.apache.commons.beanutils, implementationVendor=Apache Software Foundation, implementationVersion=1.4-dev, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[org.apache.commons.collections, implementationVendor=Apache Software Foundation, implementationVersion=2.1, specificationVendor=Apache Software Foundation, specificationVersion=2.1]
[java] Extension[org.apache.commons.digester, implementationVendor=Apache Software Foundation, implementationVersion=1.3, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[org.apache.commons.validator, implementationVendor=Apache Software Foundation, implementationVersion=1.0.1, specificationVendor=Apache Software Foundation, specificationVersion=1.0]
[java] Extension[Struts Framework, implementationVendor=Apache Software Foundation, implementationVendorId=org.apache, implementationVersion=1.1, specificationVendor=Apache Software Foundation, specificationVersion=1.1]
[java] delegate: false
[java] repositories:
[java] /WEB-INF/classes/
[java] required:
[java] ----------> Parent Classloader:
[java] java.net.FactoryURLClassLoader@13c6a8b
[java]
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/work/MainEngine/localhost/psp/WEB-INF/classes/
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/work/MainEngine/localhost/psp/WEB-INF/lib/BlowfishJ-2.0.2.jar
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/work/MainEngine/localhost/psp/WEB-INF/lib/PSP-V2-COMMON-CURRENT.jar
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/work/MainEngine/localhost/psp/WEB-INF/lib/PSP-V2-DATAPASS-CURRENT.jar
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/work/MainEngine/localhost/psp/WEB-INF/lib/activation-1.0.2.jar
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/mail-service.xml/33.mail-service.xml
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/lib/jboss-jsr77.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/localedata.jar
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/deploy/jbossweb-tomcat.sa
r/
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/lib/jboss-jaas.jar
[java] ..java.net.FactoryURLClassLoader@13c6a8b
[java] ..org.jboss.mx.loading.UnifiedClassLoader3@1a1ff9{ url=file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/deploy/PSP.ear/ ,addedOrder=24}
[java] ..org.jboss.mx.loading.HeirarchicalLoaderRepository3$NoParentClassLoader@8d1800

[java] ..sun.misc.Launcher$AppClassLoader@12f6684
[java] ....file:/C:/jboss-3.2.1_tomcat-4.1.24/bin/run.jar
[java] ....file:/C:/j2sdk1.4.1_03/lib/tools.jar
[java] ..sun.misc.Launcher$ExtClassLoader@f38798
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/dnsns.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/ldapsec.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/localedata.jar
[java] ....file:/C:/j2sdk1.4.1_03/jre/lib/ext/sunjce_provider.jar
[java] ++++CodeSource: (file:/C:/jboss-3.2.1_tomcat-4.1.24/server/default/lib/jnpserve
r.jar <no certificates>)
[java] Implemented Interfaces:
[java] ++interface javax.naming.Context(513d61)
[java] ++++ClassLoader: null
[java] ++++Null CodeSource
[java] ++interface java.io.Serializable(19e8329)
[java] ++++ClassLoader: null
[java] ++++Null CodeSource
[java] 18:03:29,135 ERROR [STDERR]



So when going through Tomcat's classloader it has EVERYTHING in it. When not it's very clean. Another interesting note is when I switch back to Jetty, the classloader info looked exactly like the first one even when accessing it through the webapp. Does Jetty not create a child WebAppClassLoader like Tomcat?

Hopefully somebody has seen something like this before and can make some sense of it for me. Thanks.