[cdi-dev] Producer#dispose(T instance) and similar
Pete Muir
pmuir at redhat.com
Thu Dec 13 10:55:00 EST 2012
On 12 Dec 2012, at 11:46, Mark Struberg wrote:
> Yes, to get this summed up what seems to have been the intended way:
>
> A CDI annotated class is a 'Managed Bean' which is one kind of Bean<T>
>
> A producer method and producer field is also a Bean<T> but not referred to as 'Managed Bean' in the spec.
+1
>
>
> And this is different to what we did read and interpret/implement in OWB:
> * each Bean<T> has general features and the definitions for certain bean types (producer methods, producer fields, etc) 'specialize' this base behaviour.
>
> e.g. in OWB all @NormalScoped beans are treated the same and get interceptors and decorators. Regardless whether they came from scanning a class or returned by a producer method or field.
Mark and I discussed this specific one on IRC. Interceptors and decorators are not required to be supported for producer methods or fields. However it is not disallowed either :-)
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Arne Limburg <arne.limburg at openknowledge.de>
>> To: Mark Struberg <struberg at yahoo.de>; Pete Muir <pmuir at redhat.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Wednesday, December 12, 2012 8:50 AM
>> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>>
>> And a short addition: The introduction of chapter three suggests that a
>> producer method IS a bean...
>>
>>
>> Am 12.12.12 08:46 schrieb "Arne Limburg" unter
>> <arne.limburg at openknowledge.de>:
>>
>>> Hi Mark,
>>> Hi Pete,
>>>
>>> From reading the spec literally I must admit that Pete seems to be right
>>> and the returned object of a producer method is not a "bean" in
>> the sense
>>> of the spec. But then there are MANY parts of the spec where we MUST
>>> clarify the usage of the term "bean", because they apply to the
>> result of
>>> a producer method, too. AND for a producer method there is a Bean<T>
>>> object available (The ProcessBean event is fired, see 11.5.11) which is
>>> confusing, if the returned object is not a "bean".
>>>
>>> And my last point: The definition as Pete understands it, would result in
>>> very unexpected behavior. Consider the following producer method:
>>>
>>> @Produces
>>> @MyStereotype
>>> public MyObject produce() {
>>> ...
>>> }
>>>
>>>
>>> And the following stereotype:
>>>
>>> @Stereotype
>>> @RequestScoped
>>> @CustomQualified
>>> @CustomIntercepted
>>> public @interface MyStereotype {}
>>>
>>> where the @CustomQualified and @CustomIntercepted annotations are a
>>> qualifier and an interceptor binding.
>>> The resulting object would have @RequestScoped and @CustomQualified
>>> applied, but not @CustomIntercepted... How would we explain that to our
>>> users?
>>> This behavior is not so clear in CDI 1.0, but would become clearer in CDI
>>> 1.1.
>>> We should definitely change some clarifications in another direction.
>>> Have not looked at Decorators and produced objects, but I guess there are
>>> many things to be clarified, too…
>>>
>>> Just my two cent,
>>> Cheers,
>>> Arne
>>>
>>> Am 11.12.12 18:58 schrieb "Mark Struberg" unter
>> <struberg at yahoo.de>:
>>>
>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> 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