[cdi-dev] Doubt about bean discovery default behaviour

[JJ Snyder]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20130502/1dff81f1/attachment.html