subject:"Re\: \[weld\-dev\] CDI and @Singleton"

Re: [weld-dev] CDI and @Singleton

2013-11-22 Thread Martin Kouba

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)...

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

Re: [weld-dev] CDI and @Singleton

2013-11-22 Thread Antoine Sabot-Durand

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 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)...

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).

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!

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.

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

Re: [weld-dev] CDI and @Singleton

2013-11-22 Thread Jozef Hartinger

Yes, it should. Can you point me to the example?

On 11/22/2013 03:38 PM, Bill Burke wrote:
 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 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

Re: [weld-dev] CDI and @Singleton

2013-11-22 Thread Martin Kouba

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)...

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).

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!

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

Re: [weld-dev] CDI and @Singleton

Re: [weld-dev] CDI and @Singleton

Re: [weld-dev] CDI and @Singleton

Re: [weld-dev] CDI and @Singleton

4 matches

Site Navigation

Mail list logo

Footer information