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(a)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(a)redhat.com>
>> To: Weld <weld-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev