[cdi-dev] Producer#dispose(T instance) and similar
Mark Struberg
struberg at yahoo.de
Fri Dec 7 17:06:24 EST 2012
Well, that restriction got only introduced with CDI-1.1.
I've not noticed that, what was the reason? There is no technical necessity to do that imo!
I can see that for
@Produces @Transactional User getUser() {..}
it is ambiguous whether the @Transactional interceptor should account for the method invocation or the produced bean.
But as Arne pointed out it is in CDI-1.0 very clear what should happen with
@Produces @MyInterceptedStereotype User getUser() {}
Should we reopen CDI-59?
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Arne Limburg <arne.limburg at openknowledge.de>
> Cc: Mark Struberg <struberg at yahoo.de>; cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, December 5, 2012 4:55 PM
> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>
> 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
>>
>
More information about the cdi-dev
mailing list