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 <[email protected]> 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 <[email protected]>
>>> To: Weld <[email protected]>
>>> 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
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>> _______________________________________________
>> weld-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev
