From: Bill Burke <bburke(a)redhat.com&gt; To: Weld <weld-dev(a)lists.jboss.org&gt; 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 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&gt; >> To: Weld <weld-dev(a)lists.jboss.org&gt; >> 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

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

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

Arun Gupta has a JAX-RS example using @Singleton. Resteasy first tries to delegate to a CDI beanmanager to create the resource instance before it relies on a default mechanism. Should the BeanManager be recognizing @Singleton then? On 11/22/2013 2: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&gt; >> To: Weld <weld-dev(a)lists.jboss.org&gt; >> 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 >>