[cdi-dev] Doubt about bean discovery default behaviour

JJ Snyder j.j.snyder at oracle.com
Mon May 13 16:03:54 EDT 2013 

GF 4.0 allows you to turn off implicit scanning for the entire 
application which will work for Michel's case below.  We plan on 
improving that immediately so that individual jars can be specified too 
instead of the option only being application-wide.

Removing @Singleton as a bean-defining annotation would also work for 
Michel's case and any others that are strictly JSR 330 (as Arne points 
out) so +1 for a way to indicate that @Singleton should not be 
considered as a bean-defining annotation (Not sure we want to remove it 
for all cases as maybe someone does want it to be considered as a 
bean-defining annotation.)

On 05/09/2013 11:21 AM, Pete Muir wrote:
> Oh yes, oops.
>
> Not a bad idea.
>
> On 9 May 2013, at 16:20, Arne Limburg<arne.limburg at openknowledge.de>  wrote:
>
>> Hmm, since guava has a dependency to @Inject and not to cdi (see [1]) I
>> guess, it is just @Singleton
>> So what about explicitly excluding it from being bean-defining?
>> @Singleton is the only bean-defining annotation in JSR-330
>>
>> Regards,
>> Arne
>>
>> [1]
>> http://search.maven.org/remotecontent?filepath=com/google/guava/guava/14.0.
>> 1/guava-14.0.1.pom
>>
>>
>> Am 09.05.13 15:59 schrieb "Pete Muir" unter<pmuir at redhat.com>:
>>
>>> On 9 May 2013, at 14:59, Arne Limburg<arne.limburg at openknowledge.de>
>>> wrote:
>>>
>>>> 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?
>>> It's the @Dependent and @Singleton annotations I think.
>>>
>>>> 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
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list