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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

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(a)betha.com.br&gt; 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(a)oracle.com&gt; > To: cdi-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

On 9 May 2013, at 14:59, Arne Limburg <arne.limburg(a)openknowledge.de&gt; 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(a)redhat.com&gt;: > >> 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(a)betha.com.br&gt; >> 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(a)oracle.com&gt; >>> To: cdi-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >

Oh yes, oops. Not a bad idea. On 9 May 2013, at 16:20, Arne Limburg&lt;arne.limburg(a)openknowledge.de&gt; 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&lt;pmuir(a)redhat.com&gt;: > >> On 9 May 2013, at 14:59, Arne Limburg&lt;arne.limburg(a)openknowledge.de&gt; >> 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&lt;pmuir(a)redhat.com&gt;: >>> >>>> 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&lt;michel.graciano(a)betha.com.br&gt; >>>> 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&quot;&lt;j.j.snyder(a)oracle.com&gt; >>>>> To: cdi-dev(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev