[cdi-dev] Doubt about bean discovery default behaviour

Thu May 9 11:21:28 EDT 2013

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
>>> 
>> 
> 