[cdi-dev] Doubt about bean discovery default behaviour

Arne Limburg arne.limburg at openknowledge.de
Thu May 9 11:20:35 EDT 2013


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




More information about the cdi-dev mailing list