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