[weld-dev] CDI and @Singleton

Fri Nov 22 09:55:50 EST 2013

Dne 22.11.2013 15:37, Antoine Sabot-Durand napsal(a):
> I don’t totally agree on your point Martin : @Dependent scope is not a normal scope as well but I can inject a dependent scope bean in a normal scope bean.

Yep, but it must be passivation capable - this is explicitly written in
the spec, 6.6.3 in CDI 1.1 and 6.6.2 in CDI 1.0.

> 
> I don’t say it’s a bug since the spec seems to be a bit blur on the subject.

Yes, it's complicated.

> 
> I wanted just to stress that 
> 
> 1. Singleton don’t behave like Application Scope as it was evoked in this thread
> 2. Weld behavior changed from version 1 to 2

I agree.

> 3. Singleton is now, nearly useless since I can’t make it interact with other scope. and if something can’t be used can we say we implemented it ;) ?

IMHO javax.inject.Singleton was never useful (in connection with CDI)
because it's behaviour/lifecycle is not defined...

> 
> Antoine
> 
> 
> Le 22 nov. 2013 à 12:53, Martin Kouba <mkouba at redhat.com> a écrit :
> 
>> Antoine, I think the Weld 2.x behaviour is correct per the spec.
>> GlobalRepositoryImpl is not a passivation capable dependency (@Singleton
>> is not a normal scope)...
>>
>> M
>>
>> Dne 22.11.2013 11:54, Antoine Sabot-Durand napsal(a):
>>> In my experience, Weld 1.1.x supported @Singleton,
>>> Weld 2.x don’t support them (or not in same way).
>>>
>>> In Agorava roadmap I plan to provide implementation on other JSR 330 framework than CDI, so I have a module containing only JSR 330 compliant code. In this module I defined a Bean « GlobalRespository » with @Singleton scope. In my CDI module this bean is injected in a SessionScoped bean (inCookieProducer). Under Jboss AS 7.1.1, Glassfish 3.1.2 and EAP 6.1 the code works nicely.
>>> With Wildfly 8 and Glassfish 4.0, I have this exception when my web app start :
>>>
>>> Caused by: org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413: The bean Managed Bean [class org.agorava.cdi.InCookieProducer] with qualifiers [@Any @Default] declares passivating scope but has non-passivation-capable dependency Managed Bean [class org.agorava.oauth.GlobalRepositoryImpl] with qualifiers [@Any @Default]
>>> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:461)
>>> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
>>> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
>>> 	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
>>> 	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
>>> 	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
>>> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>>> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>>> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>>> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
>>> 	... 3 more
>>> As a workaround I had to create a @Specialize bean of my @Singleton only to set it in @ApplicationScope.
>>>
>>> Antoine Sabot-Durand /@antoine_sd
>>> ———————————————
>>> CDI co-spec lead
>>> CDI eco-system development
>>> Agorava tech lead
>>>
>>>
>>> Le 22 nov. 2013 à 09:24, Jozef Hartinger <jharting at redhat.com> a écrit :
>>>
>>>> Weld supports it but because of the reasons stated by Mark I would 
>>>> recommend avoiding it.
>>>>
>>>> On 11/22/2013 08:19 AM, Mark Struberg wrote:
>>>>> Hi Bill!
>>>>>
>>>>> This pops up quite often.
>>>>> Actually the spec is pretty much silent on this and defines nothing else than CDI being based on JSR-330. But the TCK defines that any JSR-299 container also must fully pass the JSR-330 TCK as part of the compatibility check.
>>>>>
>>>>> Means CDI containers need to support it, but it is not really defined how it should behave.
>>>>> In OWB we just treat it as alias for @ApplicationScoped. I'm not 100% sure if it's the same for Weld, but I think to remember discussing about it with either Jozef or Pete that they do it effectively the same way. Needs ack from them though.
>>>>>
>>>>> My personal suggestion is to avoid it.
>>>>>
>>>>> There is a slightly broader issue hidden in this topic actually.
>>>>> As per explanation above, each CDI container must also support scopes annotated with @Scope (from atinject, not @NormalScope from CDI). But atinject does nowhere define how to register Contexts for those scopes. In CDI we should do pickup contexts for those scopes but it's probably not well tested nor defined how those contexts should behave.
>>>>> I'd personally would expect them to just get injected without the Contextual Reference proxies but as direct Contextual Instances and otherwise be pretty much the same like standard CDI scopes. But that needs ack + wordig by my fellow CDI EG members.
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Bill Burke <bburke at redhat.com>
>>>>>> To: Weld <weld-dev at lists.jboss.org>
>>>>>> Cc:
>>>>>> Sent: Friday, 22 November 2013, 3:17
>>>>>> Subject: [weld-dev] CDI and @Singleton
>>>>>>
>>>>>> Is Weld or CDI supposed to recognize and support @javax.inject.Singleton
>>>>>> annotated classes?
>>>>>>
>>>>>> -- 
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>>>> _______________________________________________
>>>>>> weld-dev mailing list
>>>>>> weld-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>>>
>>>>> _______________________________________________
>>>>> weld-dev mailing list
>>>>> weld-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>
>>>> _______________________________________________
>>>> weld-dev mailing list
>>>> weld-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
> 