[cdi-dev] passivation capable parameters for producerMethods

[Pete Muir]

Right, IMO this is something which definitely does not make sense and there is no precedent for it.

On 30 Jun 2011, at 11:53, Mark Struberg wrote:

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