[cdi-dev] Doubt about bean discovery default behaviour

Thu May 9 09:51:51 EDT 2013

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