The CDI spec states that "WEB-INF/beans.xml indicates that WEB-INF/classes is a bean
archive" - yes. However it doesn't say a servlet injection point must be in a
bean archive, it just says it should be injected. Java EE says it won't unless
it's in a bean archive.
On 6 Feb 2012, at 17:03, Joseph Snyder wrote:
I'm confused...The CDI spec states that WEB-INF/beans.xml
indicates that WEB-INF/classes is a bean archive. So CDI is stating that the servlet
injection point should not work, not that it should work right?
On 2/6/2012 7:30 AM, Pete Muir wrote:
> Unfortunately there is kinda an overlap/conflict/mismatch (conflict is too strong,
overlap too weak ;-) between the Java EE spec and CDI here. CDI implies that the Servlet
injection point should work, however Java EE says it definitely won't. Assuming that
Java EE overrules CDI here, then you are correct, and that is how all containers I know of
> On 3 Feb 2012, at 22:28, Mark Struberg wrote:
>> yes, that is exactly what should happen.
>> Please note that you could also have a WEB-INF/classes/META-INF/beans.xml to
pickup WEB-INF/classes as bean archive.
>> I always do it that way, because Eclipse and Idea can handle this much better
when you e.g. need to debug a webapp with mvn jetty:run
>>> From: Joseph Snyder<j.j.snyder(a)oracle.com>
>>> To: cdi-dev(a)lists.jboss.org
>>> Sent: Friday, February 3, 2012 9:34 PM
>>> Subject: [cdi-dev] War with no WEB-INF/beans.xml
>>> I have a test war that does not contain WEB-INF/beans.xml. However, there is
a jar in WEB-INF/lib that does contain META-INF/beans.xml. According to the spec, 12.1,
this war contains 1 bean archive, the one in the jar. (If there were a WEB-INF/beans.xml
then there would be 2 bean archives in the war.) So when the war is deployed only the
classes in the jar are managed by the CDI container. Therefore, if there is an injection
point defined in a servlet (in WEB-INF/classes) then that injection point will never be
processed by the CDI container. Is my interpretation of the spec correct?
>>> cdi-dev mailing list
>> cdi-dev mailing list