[cdi-dev] Producer#dispose(T instance) and similar
Mark Struberg
struberg at yahoo.de
Tue Dec 11 10:07:00 EST 2012
Actually I cannot read this restriction from the old wording. Please note that the terminus 'managed bean' is well defined and any producer method is a 'managed bean' as well as explicitly defined in the spec. This is not restricted to managed beans which are just classes imo.
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Arne Limburg <arne.limburg at openknowledge.de>; cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Monday, December 10, 2012 1:37 PM
> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>
>
> 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