The MessageDrivenBean saga continues

[hirowla.ian.rowlands.three.com.au]

Hi, I'm still having MDB issues! I'm almost there, just need to clarify something with the way I should be accessing Resources in an MDB. I'm using JBoss 6.0.0 M2 with Weld 1.0.1 Final.

Firstly, here's the code for the MDB (the important bit anyway):

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "/queue/NotificationsQueue")})
public class OptinNotificationProcessor
     implements MessageListener {
    @Resource
    private MessageDrivenContext context;

    @Inject
    private Logger logger;

    public void onMessage(Message message) {
        etc etc
    }

The problem occurs when I use the @Resource tag with the MessageDrivenContext. If I take that out, the code sort of works (of course, I don't have a context which will be an issue if I get an exception!). But if I put it in, I get the stacktrace shown at the bottom of this post. As an aside, the logger injection works if I remove the @Resource tag so I know injection is working.

I'd just like to clarify that this is a valid way to get the context for the MDB? If not, what should I be doing? Is there a different recommended way?

Thanks,

Ian

10:05:18,673 ERROR [org.jboss.aspects.tx.TxPolicy] javax.ejb.EJBTransactionRolledbackException: java.lang.reflect.InvocationTargetException
10:05:18,673 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] Unexpected error delivering message delegator->JBossMessage[5192369433149442]:PERSISTENT, deliveryId=0: javax.ejb.EJBTransactionRolledbackException: java.lang.reflect.InvocationTargetException
     at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:115)
     at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
     at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
     at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:299)
     at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:152)
     at $Proxy281.onMessage(Unknown Source)
     at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:179)
     at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
     at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
     at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_6405193.invoke(SessionAspect_z_handleRun_6405193.java)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
     at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
     at org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
     at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:236)
     at org.jboss.resource.work.WorkWrapper.run(WorkWrapper.java:172)
     at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
     at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:780)
     at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
     at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:800)
     at java.lang.Thread.run(Thread.java:619)
     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
     at org.jboss.ejb3.interceptors.container.AbstractContainer.invokeCallback(AbstractContainer.java:262)
     at org.jboss.ejb3.EJBContainer.invokeCallback(EJBContainer.java:1161)
     at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:1170)
     at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:1181)
     at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:93)
     at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:73)
     at org.jboss.ejb3.pool.StrictMaxPool.get(StrictMaxPool.java:146)
     at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:58)
     at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
     at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
     ... 34 more
Caused by: java.lang.reflect.InvocationTargetException
     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:597)
     at org.jboss.ejb3.interceptors.aop.LifecycleCallbackInterceptorMethodLazyInterceptor.invoke(LifecycleCallbackInterceptorMethodLazyInterceptor.java:109)
     at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:79)
     at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
     at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_6405193.invoke(InvocationContextInterceptor_z_setup_6405193.java)
     at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:79)
     at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
     at org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:79)
     at org.jboss.ejb3.interceptors.container.AbstractContainer.invokeCallback(AbstractContainer.java:258)
     ... 43 more
Caused by: java.lang.RuntimeException: Error looking up java:comp/env/package.optin.notifier.OptinNotificationProcessor/context in JNDI
     at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:51)
     at org.jboss.weld.util.Beans.injectEEFields(Beans.java:755)
     at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:121)
     at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:51)
     at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116)
     at org.jboss.weld.integration.ejb.SessionBeanInterceptor.postConstruct(SessionBeanInterceptor.java:97)
     ... 55 more
Caused by: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NamingException: Could not dereference object [Root exception is java.lang.NullPointerException]]
     at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1356)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:819)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688)
     at javax.naming.InitialContext.lookup(InitialContext.java:392)
     at org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:47)
     ... 60 more
Caused by: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.NullPointerException]
     at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1508)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:824)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688)
     at javax.naming.InitialContext.lookup(InitialContext.java:392)
     at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1350)
     ... 65 more
Caused by: java.lang.NullPointerException
     at org.jboss.ejb3.EJBContextFactory.getObjectInstance(EJBContextFactory.java:57)
     at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
     at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1483)
     at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1500)
     ... 70 more

[hirowla.ian.rowlands.three.com.au]

Should I be filing a JIRA issues for this? I assume it's a main WELD issue and not an integration issue, or is that a wrong assumption?

[nickarls]

Yes, please do. Hard to tell where the issue is but file it under WELD so at least we have it somewhere.

[pmuir]

Definitely a bug in Weld! Please make sure we get an issue for this.

[nickarls]

I'm looking into it, I have it reproduced...

[nickarls]

OK, did some more digging. When the SessionBeanInterceptor performs the resource injections it goes resolving the context and ends up with

java:comp/env/org.jboss.weld.tests.ejb.mdb.MilkMan/context

if we look at the JNDI tree of the AS at that moment we have

java:comp namespace of the component
jboss.j2ee:ear=org.jboss.weld.tests.ejb.mdb.EJBTest.ear,jar=org.jboss.weld.tests.ejb.mdb.EJBTest.jar,name=MilkMan,service=EJB3 :

  +- EJBContext (class: javax.ejb.EJBContext)
  +- TransactionSynchronizationRegistry[link -> java:TransactionSynchronizationRegistry] (class: javax.naming.LinkRef)
  +- UserTransaction (class: org.jboss.ejb3.tx.UserTransactionImpl)
  +- env (class: org.jnp.interfaces.NamingContext)
  |   +- org.jboss.weld.tests.ejb.mdb.MilkMan (class: org.jnp.interfaces.NamingContext)
  |   |   +- context[link -> java:comp/EJBContext] (class: javax.naming.LinkRef)
  |   +- org.jboss.weld.integration.ejb.SessionBeanInterceptor (class: org.jnp.interfaces.NamingContext)
  |   |   +- beanManager[link -> java:app/BeanManager] (class: javax.naming.LinkRef)
  |   |   +- ejbContext[link -> java:comp/EJBContext] (class: javax.naming.LinkRef)
  |   +- org.jboss.weld.integration.ejb.interceptor.Jsr299BindingsInterceptor (class: org.jnp.interfaces.NamingContext)
  |   |   +- beanManager[link -> java:app/BeanManager] (class: javax.naming.LinkRef)
  +- ORB[link -> java:/JBossCorbaORB] (class: javax.naming.LinkRef)

the context appears to be a link to EJBContext. Is this supposed to be like that?

[hirowla.ian.rowlands.three.com.au]

Forgot to say I posted a JIRA for this (and for my other one, luckily Pete was on the ball and found that one!)

https://jira.jboss.org/jira/browse/WELD-463

[mbogoevici]

@Nik - the link to java:comp/EJBContext is correct, this is the default JNDI location for @Resource EJBContext;

Now, testing this quickly outside the CDI realm, it is that particular JNDI lookup that fails during the postconstruction an EJB. It seems to me like postconstruction does not pass through the chain of AOP interceptors that will push the BeanContext of the bean on the thread local context. This is affecting us since we do injection on postconstruction.

I am testing against the JBoss AS trunk (which uses the naming deployers), so results may vary slightly.

My opinion is that we should be able work around this particular issue relatively easily by treating injection of EJBContext and derivates distinctly, so unless someone else has a better idea or is just quicker :) I could grab and fix this while working around other weld-int issues.

[nickarls]

Actually, we've been barking up the wrong... JNDI-tree ;-)

Pete hinted that we shouldn't try to inject the Resources stuff and we need a new InjectionTarget implementation that keeps away from this.

[nickarls]

Fixed in trunk

[mbogoevici]

That's pretty cool - actually I haven't noticed that MDBs do not follow the SessionBean general pattern of not getting their EE resources injected by Weld.

Anyway, the cause of the JNDI-related problem is captured here https://jira.jboss.org/jira/browse/EJBTHREE-2038.

But, as you and Pete said, we can avoid this altogether.