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 <mko...@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 <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 >>> > _______________________________________________ weld-dev mailing list weld-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev
