Re: [cdi-dev] passivation capable parameters for producerMethods

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