[cdi-dev] Doubt about bean discovery default behaviour

[Martin Kouba]

Hi Michel,

@Inject is not a bean defining annotation (2.5 Bean defining
annotations), so it should not affect bean discovery at all. Furthermore
guava jar does not contain a beans.xml file. So the only suspect is
javax.inject.Singleton, which IMHO shouldn't be a bean defining
annotation either as it is not a valid CDI scope. AFAIK Weld does not
consider Singleton to be a bean defining annotation (so it's probably an
integrator issue).

Re default behaviour:
* your bean archive is an explicit bean archive (contains a beans.xml
file with no version number), the container discovers each Java class,
interface or enum deployed in an explicit bean archive
* when determining which archives are bean archives, the container must
consider library jars, EJB jars or application client jars, the
WEB-INF/classes directory of a war, directories in the JVM classpath
(12.1 Bean archives)
(AFAIK this is basically the same as in CDI 1.0)

Martin

Dne 29.4.2013 19:01, Michel Graciano napsal(a):
> 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
> 

-- 
Martin Kouba
JBoss Quality Assurance Engineer
CDI TCK lead
Red Hat, Czech Republic