[cdi-dev] passivation capable parameters for producerMethods

[Mark Struberg]

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.