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
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
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  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"?>
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.
Pesquisa e Desenvolvimento
Betha Sistemas Ltda.