[cdi-dev] Producer#dispose(T instance) and similar
Martin Kouba
mkouba at redhat.com
Wed Dec 12 03:34:07 EST 2012
In my opinion "Managed bean" != "Producer".
It's a different kind of bean as stated in "Chapter 3. Programming model":
The container provides built-in support for injection and contextual
lifecycle management of the following kinds of bean:
* Managed beans
* Session beans
* Producer methods and fields
* Resources (Java EE resources, persistence contexts, persistence units,
remote EJBs and web services)
And of course every kind of bean results in a Bean<T>...
M
Dne 11.12.2012 18:58, Mark Struberg napsal(a):
> so a producer method in Weld does not result in a Bean<T> and is not being returned by BeanManager#getBeans() ?
>
> 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: Tuesday, December 11, 2012 4:11 PM
>> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>>
>> Agreed, managed bean is a well defined term:
>>
>> " 3.1. Managed beans
>>
>> A managed bean is a bean that is implemented by a Java class."
>>
>> So I'm pretty sure producers aren't managed beans.
>>
>>
>> On 11 Dec 2012, at 16:07, Mark Struberg wrote:
>>
>>> 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