JBossDeveloper

Personally, I'm inclined to lean towards Nicklas' side, with the caveat that the container should silent swallow these beans rather than kick out the entire archive.  For one, the spec clearly states that all objects in the archive that has a beans.xml in the appropriate place are managed beans.  Second, there's this code in weld's sessionbean class:

   /**
    * Validates the bean type
    */
   private void checkEJBTypeAllowed()
   {
      if (ejbDescriptor.isMessageDriven())
      {
         throw new DefinitionException(MESSAGE_DRIVEN_BEANS_CANNOT_BE_MANAGED, this);
      }
   }

Which to me says that weld kicks out MDBs, which we also know by the spec to be correct.  So per the spec:

1. All classes in the archive become managed beans.
2. MDBs cannot be a managed bean.
3. We have code that kicks out MDBs.

I'm inclined to say everything's working the way it should.

Of course, you could have an extension silently vetoing troublemaking beans like this ;-)

And what, call it the weld silencer?  Now the framework will sound even more like a weapon.

Actually, two things I'm really trying to figure out, since we just switched to extensions, (if they even make sense to) is to make a clean way to boot DNA and Infinispan, without hard coding too much logic.  I think for DNA I just need to start using their XML format (which, I really really don't want to).

Nicklas Karlsson wrote on Dec 27, 2009 17:21:


BTW, is there anything in the spec that goes against my reasoning (or would allow for MDBs to just be ignored instead of trying to make them managed beans as all other stuff in the BDA)?

The spec says that only session beans are CDI beans. Read 3.1.1 and 3.2. No other class is a bean unless you have some portable extension doing some magic.

However, nothing in the spec says or implies that you can't deploy an MDB in a bean archive. Nowhere do we say that all classes in a bean archive are beans. Definitely not. The exception thrown here is complete nonsense. Read section 12.3 to see what the container should really do.

the spec clearly states that all objects in the archive that has a beans.xml in the appropriate place are managed beans.

The spec does not say that. Read chapter 12 and section 5.1 to see what the spec really says.

I'm inclined to say everything's working the way it should.

No, that exception should not be thrown.

OK, that was what I was looking for. The over-eager validation probably comes from taking one sentence too literarily

Gavin,

Assuming you're talking about 5.1.2, I think it needs some clarification then.

5.1.2. Enabled and disabled beans

To me at least, specialization doesn't apply to an MDB (though earlier on in the doc, there are special notes around session beans).  Maybe it's supposed to, e.g. implementing MessageListener or being annotated @MessageDriven forces it to be specialized (Or putting it in ejb-jar.xml as an MDB marks it as specialized).  The other 3 criteria seem to match what's being discussed in the thread.

1. It's deployed in a bean archive. (true)
2. It's not a producer method or field of a disabled.
3. It's not an alternative.

However, my misunderstanding comes from what's stated in 12.3, where it is stated The container automatically discovers ... session beans ...

So what's supposed to happen first, auto discovery then enable/disable? I would assume so, so then the issue is that it's discovering MDBs when it shouldn't?

Assuming you're talking about 5.1.2

5.1.2 is pretty much irrelevant here. 5.1.2 is defining what beans are enabled, not what things are beans. We should not even be getting to 5.1.2, since an MDB is not a bean in the sense of the CDI spec (see the preamble of ch3).

So what's supposed to happen first, auto discovery then enable/disable?

Of course.

I would assume so, so then the issue is that it's discovering MDBs when it shouldn't?

Exactly. An MDB is not a bean in the sense of the CDI spec, so it does not trigger the last item of the first bullet list in 12.3, nor the first item of the last bullet list. (It does, however, trigger the 4th bullet point of the first bullet list in 12.3, since it is a Java EE component class supporting injection, according to the EE spec.)

In this case, Weld is trying to create a Bean object for a class which is not a bean.

In general, the spec can't contain an exhaustive list of things which don't trigger exceptions, since this is essentially open-ended. The assumption is always that if something is not explicitly prohibited by the CDI spec or by some other platform spec, then the EE container should not throw an exception. On the other hand, the spec can't contain an exhaustive list of things which the container is not required to support. The assumption is always that if some container functionality is not explicitly required by the CDI spec or by some other platform spec, then the EE container is not required to support that behavior.

In this case, the CDI spec does not say that MDBs are beans, so the CDI container is not required to support injection of MDBs into other things (which would be anyway pretty useless and contrary to the invocation semantics of an MDB). But nor does the CDI spec say that MDBs in a bean archive trigger exceptions. So the correct interpretation of the spec is that you are allowed to put MDBs in a bean archive, but you won't be able to inject them into other things. That makes sense, right?

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

I am having exactly the same issue, simply annotating a bean as @MessageDriven causes an error when deploying my archive - in a Java EE 6 project with CDI enabled in Glassfish

Did anybody manage to work out how I could use a MDB under these circumstances?

This is my error:

org.glassfish.deployment.common.DeploymentException: Message Driven Beans can't be Managed Beans
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:169)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
        at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
        at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
        at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
        at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
        at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.weld.DefinitionException: Message Driven Beans can't be Managed Beans
        at org.jboss.weld.bean.SessionBean.checkEJBTypeAllowed(SessionBean.java:313)
        at org.jboss.weld.bean.SessionBean.initialize(SessionBean.java:122)
        at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:111)
        at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:151)
        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:367)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)
        ... 30 more

Upgrade to 1.0.1.CR1/CR2, it should be fixed there.