Hi JJ,
I have create a sample app to reproduce it and uploaded to my github[1]. It is a really
simple sample where I have no classes, just a WAR with guava-14.0.1.jar in the WEB-INF/lib
folder.
When I try to deploy the app I have the following exception:
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>)]
I have tested GF4 with the property you sent me before and it worked. Now I can deploy our
app. I am facing another issues with GF now but looks like it is not related to CDI, so it
is story for another thread in another place.
Now the question is: Is this behaviour expected by spec? It looks like a serious
regression to me, since the impact is huge for most applications and no clear warning or
advise is given in the spec in this matter.
The most close words about this I found in the spec I downloaded at
cdi-spec.org is '
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. ', but it is not totally clear to me, mainly
because it is now up to the container to define something that I am used to take for
granted in CDI 1.0.
I haven't tested it outside GF, maybe all this is just GF issues, so I am sorry for
any inconvenience .
Regards
[1]
https://github.com/mgraciano/cdi-1.1-test/tree/master/GF4IssueTest
--
Michel Graciano
Pesquisa e Desenvolvimento
Betha Sistemas Ltda.
Telefone: +55 (48) 3431-0733
Ramal: 4863
----- Original Message -----
From: "JJ Snyder" <j.j.snyder(a)oracle.com>
To: cdi-dev(a)lists.jboss.org
Sent: Thursday, May 2, 2013 11:29:40 AM
Subject: Re: [cdi-dev] Doubt about bean discovery default behaviour
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. 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.
_______________________________________________
cdi-dev mailing list cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev