[cdi-dev] passivation capable parameters for producerMethods

Mark Struberg struberg at yahoo.de
Thu Jun 30 06:34:10 EDT 2011


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 at adam-bien.com> wrote:

> From: Adam Bien <abien at adam-bien.com>
> Subject: Re: [cdi-dev] passivation capable parameters for producerMethods
> To: "Mark Struberg" <struberg at yahoo.de>
> Cc: "Pete Muir" <pmuir at redhat.com>, cdi-dev at 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 at redhat.com>
> wrote:
> > 
> >> From: Pete Muir <pmuir at redhat.com>
> >> Subject: Re: [cdi-dev] passivation capable
> parameters for producerMethods
> >> To: "Mark Struberg" <struberg at yahoo.de>
> >> Cc: cdi-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> 
> 



More information about the cdi-dev mailing list