[cdi-dev] Producer#dispose(T instance) and similar

[Pete Muir]

Hey Arne,

No, they can't :-) It's specifically called out in Chapter 8 and Chapter 9 that decorators and interceptors aren't applied to the result of producer methods.

Pete

On 5 Dec 2012, at 14:47, Arne Limburg wrote:

> Hi Pete,
> 
> 
> A little of topic and I don't want to disturb your discussion, but:
> 
> Beans produced by producer methods CAN have interceptors as stereotypes
> are supported on producer methods.
> 
> Cheers,
> Arne
> 
> Am 04.12.12 17:46 schrieb "Pete Muir" unter <pmuir at redhat.com>:
> 
>> Hi Mark, I'll try to answer inline, but I'm missing a bit of background
>> about what you are doing...
>> 
>> On 4 Dec 2012, at 14:20, Mark Struberg wrote:
>> 
>>> Another problem probably being an interceptor on the @Disposes method
>>> itself.
>>> Where does the Proucer#dispose(T instance) get the interceptor from?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: Mark Struberg <struberg at yahoo.de>
>>>> To: cdi-dev <cdi-dev at lists.jboss.org>
>>>> Cc: 
>>>> Sent: Tuesday, December 4, 2012 3:16 PM
>>>> Subject: [cdi-dev] Producer#dispose(T instance) and similar
>>>> 
>>>> Hi!
>>>> 
>>>> I'm currently stumbling over implementing
>>>> 
>>>> Producer#dispose(T instance) properly
>>>> 
>>>> The Producer#produce(CreationalContext)
>>>> 
>>>> has the CreationalContext parameter but the dispose
>> 
>> Right, it would have been good to have included it here. I'm not sure why
>> it wasn't, however I don't believe that it causes a problem with the CDI
>> 1.0 spec, but just limits us going forward.
>> 
>>>> and others do not have it.
>> 
>> Yes.
>> 
>>>> 
>>>> Problem here is that a Producer could probably get exchanged via a
>>>> portable 
>>>> extension via ProcessProducer#setProducer(Producer)
>> 
>> Yes, this is definitely supported
>> 
>>>> so it could be from a
>>>> foreign source which must not know anything about container
>>>> implementation 
>>>> details.
>> 
>> Yes.
>> 
>> I think the critical part of the spec to understand this is 11.2. I'm
>> quoting here from the CDI 1.1 spec, into which we have add the
>> clarification that "The instance returned by produce() may be a proxy.".
>> The part about building interceptors and decorators is there in CDI 1.0.
>> 
>>> For a Producer that represents a class:
>>> 
>>> 	€ produce() calls the constructor annotated @Inject if it exists, or
>>> the constructor with no parameters otherwise, as defined in
>>> [instantiation], and returns the resulting instance. If the class has
>>> interceptors,produce() is responsible for building the interceptors and
>>> decorators of the instance. The instance returned by produce() may be a
>>> proxy.
>>> 
>>> 	€ dispose() does nothing.
>> 
>> and
>> 
>>> For a Producer that represents a producer method or field:
>>> 
>>> 	€ produce() calls the producer method on, or accesses the producer
>>> field of, a contextual instance of the bean that declares the producer
>>> method, as defined in [methods].
>>> 
>>> 	€ dispose() calls the disposer method, if any, on a contextual
>>> instance of the bean that declares the disposer method, as defined in
>>> [methods], or performs any additional required cleanup, if any, to
>>> destroy state associated with a resource.
>> 
>> Now, let me start to break down your sentence :-)
>> 
>>>> 
>>>> What now about having an interceptor on @PreDestroy?
>> 
>> For a start, it's worth remembering interceptors can only be associated
>> with beans defined by a class. If the bean is a producer, then you can't
>> intercept the instance produced (only the invocation of the producer).
>> 
>>>> This is what you get if
>>>> your interceptor has a at PreDestroy method himself as per the
>>>> interceptors and EJB
>>>> specs. That would mean that the instance passed to dispose() whould be
>>>> the 
>>>> proxy? That purely sounds wrong to me.
>> 
>> Based on my comment from above, I think it's clear that dispose() should
>> never try to invoke predestroy methods. That is the job of
>> InjectionTarget.preDestroy(). I would expect a proxy to be passed to
>> preDestroy().
>> 
>>> 
>>> 
>>>> 
>>>> Another issue being InjectionTarget#postConstruct() only having the
>>>> instance T 
>>>> as well. Now what about @PostConstruct interceptors as defined in the
>>>> interceptors spec?
>> 
>> Again, I would expect a proxy to be passed to postConstruct(). Anyway,
>> I'm not sure why you need access to the creational context in the
>> postConstruct()? Here you should just invoke the postConstruct callback,
>> which should create any new dependent objects.
>> 
>>>> Currently we have a dirty hack in OWB to pass over the
>>>> CreationalContext which
>>>> contains the dependent scoped interceptors for our own Producers and
>>>> InjectionTargets. But I have no clue yet how that should get
>>>> implemented if one
>>>> plugs in a portable Producer via an Extension ^^
>>>> 
>>>> Who is responsible of performing the interception? The Producer? Or
>>>> must the 
>>>> instance being handed into already be a Proxy?
>> 
>> The instance returned from produce() should have interceptors and
>> decorators applied.
>> 
>> Please let me know if above makes sense, it took me a while to work out
>> whether what was defined was sane. After quite a lot of thinking +
>> talking to Jozef and Stuart I came to the conclusion it was, but  if you
>> can poke holes then please do!
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>