[cdi-dev] Producer#dispose(T instance) and similar
Pete Muir
pmuir at redhat.com
Mon Dec 10 07:37:02 EST 2012
On 7 Dec 2012, at 22:06, Mark Struberg wrote:
> Well, that restriction got only introduced with CDI-1.1.
CDI 1.0 didn't require an impl to support this. To quote:
"Interceptor bindings may be used to associate interceptors with any managed bean that is not itself an interceptor or decor- ator or with any EJB session or message-driven bean."
"Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
The restriction was just making it explicit, because people thought it should work.
>
> I've not noticed that, what was the reason? There is no technical necessity to do that imo!
Maybe, but that isn't the way the spec is written in 1.0 :-) We can change it for sure, but it's a feature request.
>
> 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