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> wrote:
From: Adam Bien <abien(a)adam-bien.com>
Subject: Re: [cdi-dev] passivation capable parameters for producerMethods
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: "Pete Muir" <pmuir(a)redhat.com>, 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>
wrote:
>
>> From: Adam Bien <abien(a)adam-bien.com>
>> Subject: Re: [cdi-dev] passivation capable
parameters for producerMethods
>> To: "Mark Struberg" <struberg(a)yahoo.de>
>> Cc: "Pete Muir" <pmuir(a)redhat.com>,
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>
>> wrote:
>>>
>>>> From: Pete Muir <pmuir(a)redhat.com>
>>>> Subject: Re: [cdi-dev] passivation
capable
>> parameters for producerMethods
>>>> To: "Mark Struberg" <struberg(a)yahoo.de>
>>>> 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
>>
>>
>>