[cdi-dev] Doubt about bean discovery default behaviour

Thu May 9 09:59:42 EDT 2013

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
> 