[cdi-dev] Producer#dispose(T instance) and similar
Mark Struberg
struberg at yahoo.de
Wed Dec 12 05:46:54 EST 2012
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.
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.
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