[cdi-dev] passivation capable parameters for producerMethods

[Adam Bien]

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