[cdi-dev] Doubt about bean discovery default behaviour

[Michel Graciano]

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. R eading 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20130429/6773608b/attachment.html