[cdi-dev] Doubt about bean discovery default behaviour

Thu May 9 09:59:00 EDT 2013

Hi,

This is an issue for all JSR-330 jars that are no CDI jars (i.e. All
spring and guice applications). They cannot be deployed in a Java EE 7
server currently.

Maybe we should remove @javax.inject.Singleton from being a bean-defining
annotation. Or which annotation is causing the issue here?

Regards,
Arne

Am 09.05.13 15:51 schrieb "Pete Muir" unter <pmuir at redhat.com>:

>Hi
>
>Apologies for the delay in responding.
>
>This is indeed an issue CDI 1.1, and is something that we were aware of
>and raised as a potential issue when discussing this feature.
>
>Fortunately we do have the "get out clause" in the spec that you mention,
>which I believe we can use to essentially produce a blacklist of jars in
>the app server that shouldn't be scanned (such as guava).
>
>JJ, Jozef, Stuart, WDYT?
>
>Also, any ideas of how we can address this better in the spec in the MR?
>
>Pete
>
>On 3 May 2013, at 20:45, Michel Graciano <michel.graciano at betha.com.br>
>wrote:
>
>> Hi JJ,
>> I have create a sample app to reproduce it and uploaded to my
>>github[1]. It is a really simple sample where I have no classes, just a
>>WAR with guava-14.0.1.jar in the WEB-INF/lib folder.
>> When I try to deploy the app I have the following exception:
>> 
>> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
>>dependencies for type [Set<Service>] with qualifiers [@Default] at
>>injection point [[BackedAnnotatedParameter] Parameter 1 of
>>[BackedAnnotatedConstructor] @Inject
>>com.google.common.util.concurrent.ServiceManager(Set<Service>)]
>> 
>> I have tested GF4 with the property you sent me before and it worked.
>>Now I can deploy our app. I am facing another issues with GF now but
>>looks like it is not related to CDI, so it is story for another thread
>>in another place.
>> 
>> Now the question is: Is this behaviour expected by spec? It looks like
>>a serious regression to me, since the impact is huge for most
>>applications and no clear warning or advise is given in the spec in this
>>matter.
>> The most close words about this I found in the spec I downloaded at
>>cdi-spec.org is 'For compatibility with Contexts and Dependency 1.0,
>>products must contain an option to cause an archive to be ignored by the
>> container when no beans.xml is present.', but it is not totally clear
>>to me, mainly because it is now up to the container to define something
>>that I am used to take for granted in CDI 1.0.
>> 
>> I haven't tested it outside GF, maybe all this is just GF issues, so I
>>am sorry for any inconvenience.
>> 
>> Regards
>> [1]https://github.com/mgraciano/cdi-1.1-test/tree/master/GF4IssueTest
>> -- 
>> Michel Graciano 
>> Pesquisa e Desenvolvimento
>> Betha Sistemas Ltda.
>> Telefone: +55 (48) 3431-0733
>> Ramal: 4863 
>> 
>> From: "JJ Snyder" <j.j.snyder at oracle.com>
>> To: cdi-dev at lists.jboss.org
>> Sent: Thursday, May 2, 2013 11:29:40 AM
>> Subject: Re: [cdi-dev] Doubt about bean discovery default behaviour
>> 
>> Michel,
>> Auto-discovery is enabled by default for GlassFish.  So it will scan
>>all archives in the application for bean-defining annotations.  You can
>>disable this by doing the following:
>> asadmin set 
>>configs.config.server-config.cdi-service.enable-implicit-cdi=false
>> 
>> Can you send me your app?  I'll take a deeper look into it.
>> 
>> JJ
>> 
>> On 04/29/2013 01:01 PM, Michel Graciano wrote:
>> Hi all,
>> I have been reading the CDI spec and did some little tests with a
>>prototype we have here and I am facing a issue when I deploy our
>>application at GF 4 (which has guava as ine of the dependencies):
>> 
>> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied
>>dependencies for type [Set<Service>] with qualifiers [@Default] at
>>injection point [[BackedAnnotatedParameter] Parameter 1 of
>>[BackedAnnotatedConstructor] @Inject
>>com.google.common.util.concurrent.ServiceManager(Set<Service>)]
>> 
>> Basically I am facing it because guava has some classes annotated with
>>@Inject and the container by default are scanning all the deps.
>> 
>> I have read the spec and for me it is not clear what the default
>>behaviour is, if the container should or not scan all the dependencies
>>when my app is supposedly following 1.0 spec (see our beans.xml above).
>>Digging a little bit more, I found a issue [1] which says basically that
>>'Auto-discover is false by default in CDI 1.1 and the attribute is
>>required...', which for me means that by default the container should
>>work as CDI 1.0 at this matter. Reading the spec a little further I
>>found 'For compatibility with Contexts and Dependency 1.0, products must
>>contain an option to cause an archive to be ignored by the container
>>when no beans.xml is present.' (which is the case for guava library)
>>which could means that by default the container will not work as
>>expected by CDI 1.0, so we have an incompatible change here.
>> 
>> Our beans.xml file has just this content:
>> 
>> <?xml version="1.0" encoding="UTF-8"?>
>> <beans xmlns="http://java.sun.com/xml/ns/javaee"
>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>>http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
>> </beans>
>> 
>> My question here is: Am I facing a issue at Weld/GF 4
>>(glassfish-4.0-b86) or it is the default behaviour expected for CDI 1.1
>>specification?
>> 
>> IMHO this behaviour should be clear at the specification, maybe
>>following as did by JSR 344 adding a 'Breakages in Backward
>>Compatibility' section for changelog section if it is the case.
>> 
>> I am sorry if this question have already been asked, but I was unable
>>to find it (I swear I tried :).
>> 
>> Thanks in advance.
>> [1] https://issues.jboss.org/browse/CDI-321
>> -- 
>> Michel Graciano 
>> Pesquisa e Desenvolvimento
>> Betha Sistemas Ltda.
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> 
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>_______________________________________________
>cdi-dev mailing list
>cdi-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev