NameNotBoundException in MDB, but bound in WAR Servlet

[johndubchak]

I have an EAR application deployed on JBoss 4.2.2 running on OS X.

In a WAR, I am loading a servlet during application startup to bootstrap some configuration within an object then binding that object to the JNDI java:comp/env namespace.

When I look in the jmx-console, I see that the object is available under the following heading:

java:comp namespace of the my-ear.ear/my-war.war application.

I have an MDB EJB that is listening on a queue for messages and upon receiving a message, tries to retrieve the object from the same JNDI namespace but, instead, gets the following error:

javax.naming.NameNotFoundException: MyObject not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667)
at org.jboss.ejb3.naming.MultiplexerContext.lookup(MultiplexerContext.java:233)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:774)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.eliteswa.esb.messaging.naming.MessageServiceLocator.locate(MessageServiceLocator.java:62)
at com.eliteswa.esb.broker.util.DefaultBrokerNaming.getBroker(DefaultBrokerNaming.java:57)
at com.eliteswa.mdb.ServiceCommandProcessor.getBroker(ServiceCommandProcessor.java:118)
at com.eliteswa.mdb.ServiceCommandProcessor.onMessage(ServiceCommandProcessor.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:249)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138)
at $Proxy149.onMessage(Unknown Source)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:891)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
at org.jboss.mq.SpySession.run(SpySession.java:323)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:237)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
at java.lang.Thread.run(Thread.java:613)

I know I'm probably not doing something right and hope that someone can help clear up my misunderstanding.

Thanks,
John

[jaikiran]

In a WAR, I am loading a servlet during application startup to bootstrap some configuration within an object then binding that object to the JNDI java:comp/env namespace.

When I look in the jmx-console, I see that the object is available under the following heading:

java:comp namespace of the my-ear.ear/my-war.war application.

When you add the object to the java:comp/env namespace of the WAR, it becomes available to your WAR component. Each component in your application have their own java:comp/env namespace (environment naming context - ENC). When you try to lookup this object from the MDB (which has a different ENC), the MDB will not be able to find this since it looks in its own ENC. To make the object available in the ENC of the MDB, you will have to add a resource-ref in the ejb-jar.xml of this bean, to point to the object that you have bound in the jndi tree.