Re: [cdi-dev] passivation capable parameters for producerMethods
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.