If a managed bean which declares a passivating scope: * has a non-transient injected field, <- that part is fine bean constructor parameter or initializer method parameter that does not resolve to a passivation capable dependency, or

From: Pete Muir <pmuir(a)redhat.com&gt; Subject: Re: [cdi-dev] passivation capable parameters for producerMethods To: "Mark Struberg" <struberg(a)yahoo.de&gt; Cc: cdi-dev(a)lists.jboss.org Date: Thursday, June 30, 2011, 7:07 AM On 29 Jun 2011, at 13:57, Mark Struberg wrote: > Hi! > > Section 6.6.4 declares that: > >> If a producer method declares a passivating scope and: >> .. >> * has a parameter that does not resolve to a passivation capable >> dependency, >> then the container automatically detects the problem and >> treats it as a deployment problem. > > What is the reason for this restriction? Not 100% sure. Any one else know? > Something like > > @Produces @SessionScoped @AutoAuthenticated > public User getCurrentUser(EntityManager em) { >   return ... > > (EntityManager gets produced as @RequestScoped) would not be allowed because EntityManager is not Serializable. Actually as long as you use a resource producer field then the CDI container must make it passivation capable ;-) But that just makes it a bad example, it doesn't solve the problem.

From: Pete Muir <pmuir(a)redhat.com&gt; Subject: Re: [cdi-dev] passivation capable parameters for producerMethods To: "Mark Struberg" <struberg(a)yahoo.de&gt; Cc: cdi-dev(a)lists.jboss.org Date: Thursday, June 30, 2011, 7:38 AM On 30 Jun 2011, at 08:34, Mark Struberg wrote: > Yes, the example with the EntityManager might be confusing. Just s/EntityManager/SomeOtherClass/ :) > (Btw, only EntityManagers provided by producer fields are 'injectable resources' as per the spec and thus made auto-serializable. Yes, that's what I wrote ;-) > Which is btw imo technically impossible if the EM contains locking states. But that's another story... I don't believe CDI requires you to actually restore the same EM on the other side of passivation, it's just the reference must be passivation capable... We should investigate this. > > I wonder if Weld does implement this at all. We recently got an issue reported for OWB that some parts of Seam are not working. It does IIRC. > It looks like OWB performs those tests and fails with a deployment exception whereas Weld doesn't detect it. Can you elaborate with the issue? > Are there TCK tests for this behaviour? There are some. > > I'd favour to drop that language and functionality if noone objects. Please file a CDI issue and we can discuss. > > Btw, there are also a few other occurrences : > 6.6.4 >> If a managed bean which declares a passivating scope: >> * has a non-transient injected field, <- that part is fine >> bean constructor parameter or initializer method parameter >> that does not resolve to a passivation capable dependency, or > > But I don't get the contructor parameter and @Inject method parameter criteria. Right, it's the same thing. Add it to the issue.

I thought about it and I guess this restriction comes from the picture of using the @Inject methods and ct params as kind of dumb setters private MyClass x; public @Inject setX(MyClass x) { this.x = x; } In this 'dumb' cases it would make sense. But inject methods could contain much more intelligence - even wrap those parameters in Serializable implementations themself. So I think the restriction is just too much... LieGrue, strub --- On Thu, 6/30/11, Pete Muir <pmuir(a)redhat.com&gt; wrote: > From: Pete Muir <pmuir(a)redhat.com&gt; > Subject: Re: [cdi-dev] passivation capable parameters for producerMethods > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: cdi-dev(a)lists.jboss.org > Date: Thursday, June 30, 2011, 7:38 AM > > On 30 Jun 2011, at 08:34, Mark Struberg wrote: > >> Yes, the example with the EntityManager might be > confusing. Just s/EntityManager/SomeOtherClass/ :) >> (Btw, only EntityManagers provided by producer fields > are 'injectable resources' as per the spec and thus made > auto-serializable. > > Yes, that's what I wrote ;-) > >> Which is btw imo technically impossible if the EM > contains locking states. But that's another story... > > I don't believe CDI requires you to actually restore the > same EM on the other side of passivation, it's just the > reference must be passivation capable... We should > investigate this. > >> >> I wonder if Weld does implement this at all. We > recently got an issue reported for OWB that some parts of > Seam are not working. > > It does IIRC. > >> It looks like OWB performs those tests and fails with > a deployment exception whereas Weld doesn't detect it. > > Can you elaborate with the issue? > >> Are there TCK tests for this behaviour? > > There are some. > >> >> I'd favour to drop that language and functionality if > noone objects. > > Please file a CDI issue and we can discuss. > >> >> Btw, there are also a few other occurrences : >> 6.6.4 >>> If a managed bean which declares a passivating > scope: >>> * has a non-transient injected field, <- that > part is fine >>> bean constructor parameter or initializer method > parameter >>> that does not resolve to a passivation capable > dependency, or >> >> But I don't get the contructor parameter and @Inject > method parameter criteria. > > Right, it's the same thing. Add it to the issue. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

yes: it's not necessary ;) You can only inject parameters into methods which get called by the container (e.g. @Observes @Disposal, @Produces, @Inject methods, etc). And for all those methods, the container _must_ inject the parameters itself. There is no 'mixed' mode possible, so we don't need that annotation on parameters as it would just be redundant ;) LieGrue, strub --- On Thu, 6/30/11, Adam Bien <abien(a)adam-bien.com&gt; wrote: > From: Adam Bien <abien(a)adam-bien.com&gt; > Subject: Re: [cdi-dev] passivation capable parameters for producerMethods > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, cdi-dev(a)lists.jboss.org > Date: Thursday, June 30, 2011, 9:59 AM > On that note: is there a reason why > there is no ElementType.PARAMETER as Target in @Inject?: > > @Target(value = {ElementType.METHOD, > ElementType.CONSTRUCTOR, ElementType.FIELD}) > @Retention(value = RetentionPolicy.RUNTIME) > @Documented > public @interface Inject { > } > > > > On 30.06.2011, at 10:24, Mark Struberg wrote: > >> I thought about it and I guess this restriction comes > from the picture of using the @Inject methods and ct params > as kind of dumb setters >> >> private MyClass x; >> >> public @Inject setX(MyClass x) { >> this.x = x; >> } >> >> In this 'dumb' cases it would make sense. But inject > methods could contain much more intelligence - even wrap > those parameters in Serializable implementations themself. >> So I think the restriction is just too much... >> >> LieGrue, >> strub >> >> >> --- On Thu, 6/30/11, Pete Muir <pmuir(a)redhat.com&gt; > wrote: >> >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> Subject: Re: [cdi-dev] passivation capable > parameters for producerMethods >>> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> Cc: cdi-dev(a)lists.jboss.org >>> Date: Thursday, June 30, 2011, 7:38 AM >>> >>> On 30 Jun 2011, at 08:34, Mark Struberg wrote: >>> >>>> Yes, the example with the EntityManager might > be >>> confusing. Just s/EntityManager/SomeOtherClass/ > :) >>>> (Btw, only EntityManagers provided by producer > fields >>> are 'injectable resources' as per the spec and > thus made >>> auto-serializable. >>> >>> Yes, that's what I wrote ;-) >>> >>>> Which is btw imo technically impossible if the > EM >>> contains locking states. But that's another > story... >>> >>> I don't believe CDI requires you to actually > restore the >>> same EM on the other side of passivation, it's > just the >>> reference must be passivation capable... We > should >>> investigate this. >>> >>>> >>>> I wonder if Weld does implement this at all. > We >>> recently got an issue reported for OWB that some > parts of >>> Seam are not working. >>> >>> It does IIRC. >>> >>>> It looks like OWB performs those tests and > fails with >>> a deployment exception whereas Weld doesn't detect > it. >>> >>> Can you elaborate with the issue? >>> >>>> Are there TCK tests for this behaviour? >>> >>> There are some. >>> >>>> >>>> I'd favour to drop that language and > functionality if >>> noone objects. >>> >>> Please file a CDI issue and we can discuss. >>> >>>> >>>> Btw, there are also a few other occurrences : >>>> 6.6.4 >>>>> If a managed bean which declares a > passivating >>> scope: >>>>> * has a non-transient injected field, > <- that >>> part is fine >>>>> bean constructor parameter or initializer > method >>> parameter >>>>> that does not resolve to a passivation > capable >>> dependency, or >>>> >>>> But I don't get the contructor parameter and > @Inject >>> method parameter criteria. >>> >>> Right, it's the same thing. Add it to the issue. >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > >

oki I see. But when having multiple parameters, it could lead to confusion if not all parameters would get @Inject annotated: public void init(MyClass firstParam, @Inject AnotherClass seconsParam) {.. LieGrue, strub --- On Thu, 6/30/11, Adam Bien <abien(a)adam-bien.com&gt; wrote: > From: Adam Bien <abien(a)adam-bien.com&gt; > Subject: Re: [cdi-dev] passivation capable parameters for producerMethods > To: "Mark Struberg" <struberg(a)yahoo.de&gt; > Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, cdi-dev(a)lists.jboss.org > Date: Thursday, June 30, 2011, 10:49 AM > Yes, recognized that. Buy your sample > would be more readable: > > Instead of: public @Inject setX(MyClass x) {} > > this: public setX(@Inject MyClass x){} > > It is redundant from the implementation perspective, but > easier to read from the user perspective :-) > > I would not change anything, but only allow @Inject for > parameters. > > On 30.06.2011, at 12:34, Mark Struberg wrote: > >> yes: it's not necessary ;) >> >> You can only inject parameters into methods which get > called by the container (e.g. @Observes @Disposal, > @Produces, @Inject methods, etc). And for all those methods, > the container _must_ inject the parameters itself. >> >> There is no 'mixed' mode possible, so we don't need > that annotation on parameters as it would just be redundant > ;) >> >> LieGrue, >> strub >> >> --- On Thu, 6/30/11, Adam Bien <abien(a)adam-bien.com&gt; > wrote: >> >>> From: Adam Bien <abien(a)adam-bien.com&gt; >>> Subject: Re: [cdi-dev] passivation capable > parameters for producerMethods >>> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> Cc: "Pete Muir" <pmuir(a)redhat.com&gt;, > cdi-dev(a)lists.jboss.org >>> Date: Thursday, June 30, 2011, 9:59 AM >>> On that note: is there a reason why >>> there is no ElementType.PARAMETER as Target in > @Inject?: >>> >>> @Target(value = {ElementType.METHOD, >>> ElementType.CONSTRUCTOR, ElementType.FIELD}) >>> @Retention(value = RetentionPolicy.RUNTIME) >>> @Documented >>> public @interface Inject { >>> } >>> >>> >>> >>> On 30.06.2011, at 10:24, Mark Struberg wrote: >>> >>>> I thought about it and I guess this > restriction comes >>> from the picture of using the @Inject methods and > ct params >>> as kind of dumb setters >>>> >>>> private MyClass x; >>>> >>>> public @Inject setX(MyClass x) { >>>> this.x = x; >>>> } >>>> >>>> In this 'dumb' cases it would make sense. But > inject >>> methods could contain much more intelligence - > even wrap >>> those parameters in Serializable implementations > themself. >>>> So I think the restriction is just too > much... >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> --- On Thu, 6/30/11, Pete Muir <pmuir(a)redhat.com&gt; >>> wrote: >>>> >>>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>>> Subject: Re: [cdi-dev] passivation > capable >>> parameters for producerMethods >>>>> To: "Mark Struberg" <struberg(a)yahoo.de&gt; >>>>> Cc: cdi-dev(a)lists.jboss.org >>>>> Date: Thursday, June 30, 2011, 7:38 AM >>>>> >>>>> On 30 Jun 2011, at 08:34, Mark Struberg > wrote: >>>>> >>>>>> Yes, the example with the > EntityManager might >>> be >>>>> confusing. Just > s/EntityManager/SomeOtherClass/ >>> :) >>>>>> (Btw, only EntityManagers provided by > producer >>> fields >>>>> are 'injectable resources' as per the spec > and >>> thus made >>>>> auto-serializable. >>>>> >>>>> Yes, that's what I wrote ;-) >>>>> >>>>>> Which is btw imo technically > impossible if the >>> EM >>>>> contains locking states. But that's > another >>> story... >>>>> >>>>> I don't believe CDI requires you to > actually >>> restore the >>>>> same EM on the other side of passivation, > it's >>> just the >>>>> reference must be passivation capable... > We >>> should >>>>> investigate this. >>>>> >>>>>> >>>>>> I wonder if Weld does implement this > at all. >>> We >>>>> recently got an issue reported for OWB > that some >>> parts of >>>>> Seam are not working. >>>>> >>>>> It does IIRC. >>>>> >>>>>> It looks like OWB performs those tests > and >>> fails with >>>>> a deployment exception whereas Weld > doesn't detect >>> it. >>>>> >>>>> Can you elaborate with the issue? >>>>> >>>>>> Are there TCK tests for this > behaviour? >>>>> >>>>> There are some. >>>>> >>>>>> >>>>>> I'd favour to drop that language and >>> functionality if >>>>> noone objects. >>>>> >>>>> Please file a CDI issue and we can > discuss. >>>>> >>>>>> >>>>>> Btw, there are also a few other > occurrences : >>>>>> 6.6.4 >>>>>>> If a managed bean which declares > a >>> passivating >>>>> scope: >>>>>>> * has a non-transient injected > field, >>> <- that >>>>> part is fine >>>>>>> bean constructor parameter or > initializer >>> method >>>>> parameter >>>>>>> that does not resolve to a > passivation >>> capable >>>>> dependency, or >>>>>> >>>>>> But I don't get the contructor > parameter and >>> @Inject >>>>> method parameter criteria. >>>>> >>>>> Right, it's the same thing. Add it to the > issue. >>>> > _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> >>> > > >