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.
I don’t say it’s a bug since the spec seems to be a bit blur on the subject. 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 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 ;) ? Antoine Le 22 nov. 2013 à 12:53, Martin Kouba <[email protected]> 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 <[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 >> _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
