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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
Martin Kouba
JBoss Quality Assurance Engineer
CDI TCK lead
Red Hat, Czech Republic