On 9 May 2013, at 14:59, Arne Limburg <arne.limburg(a)openknowledge.de> wrote:
Hi,
This is an issue for all JSR-330 jars that are no CDI jars (i.e. All
spring and guice applications). They cannot be deployed in a Java EE 7
server currently.
Maybe we should remove @javax.inject.Singleton from being a bean-defining
annotation. Or which annotation is causing the issue here?
Regards,
Arne
Am 09.05.13 15:51 schrieb "Pete Muir" unter <pmuir(a)redhat.com>:
> Hi
>
> Apologies for the delay in responding.
>
> This is indeed an issue CDI 1.1, and is something that we were aware of
> and raised as a potential issue when discussing this feature.
>
> Fortunately we do have the "get out clause" in the spec that you mention,
> which I believe we can use to essentially produce a blacklist of jars in
> the app server that shouldn't be scanned (such as guava).
>
> JJ, Jozef, Stuart, WDYT?
>
> Also, any ideas of how we can address this better in the spec in the MR?
>
> Pete
>
> On 3 May 2013, at 20:45, Michel Graciano <michel.graciano(a)betha.com.br>
> wrote:
>
>> 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
>>
>> 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. 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
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev