[cdi-dev] Producer#dispose(T instance) and similar
Mark Struberg
struberg at yahoo.de
Wed Dec 12 05:39:41 EST 2012
After re-reading the spec with this hint I can see what you mean.
I think my confusion came with the fact that some paragraphs define behaviour for 'managed beans' whereas this is also needed for most (but not all) other Bean<T> like producer methods. Now I can see that producer methods are mentioned pretty often in an own paragraph (but not always) whereas producer field rules are almost never mentioned.
> " A managed bean is a bean that is implemented by a Java class."
This could also be interpreted as the return type of a producer method.
But I see that most behaviour is defined for both 'managed beans' and 'producer methods'. Again: weirdly there is often no paragraph about producer fields. Is this intentional?
I originally interpreted this as the producer method part is no XOR but only narrows ('specializes') the behaviour of the general bean rules. And if something special is defined for producer fields it further narrows the producer method behvaviour.
Maybe we got this wrong because the Producer<T> definition mixes them as well?
So what do we (OWB) 'loose' by interpreting 'managed beans' as just scanned classes (and treating producer methods completely different)?
* Decorators on producer method/fields produced
* Interceptors on producer methods/fields
* I would need to test this, but there is a chance that we currently fire both ProcessManagedBean and ProcessProducerMethod for a producermethod...
It is also not very helpful that the Logger example in 1.3.5 uses a producer method and the Logger example in this whole Decorator chapter 8.1 applies a Decorator on a produced Logger...
In OWB this sample works perfectly fine ;)
The spec also sometimes uses the term 'managed bean class':
> 10.4 Observer methods
> An observer method is a non-abstract method of a managed bean class or session bean class
There are other possible sources for confusion:
> 12.3. Bean discovery
> The container automatically discovers managed beans (according to the rules of Section 3.1.1,
> “Which Java classes are managed beans?”)
> and session beans in bean archives
> and searches the bean classes for producer methods, producer fields,
> disposer methods and observer methods.
This could give the impression that 'discovers managed beans' also accounts for producer methods. But might be only me.
LieGrue,
strub
----- Original Message -----
> From: Martin Kouba <mkouba at redhat.com>
> To: cdi-dev at lists.jboss.org
> Cc:
> Sent: Wednesday, December 12, 2012 9:34 AM
> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
>
> 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
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
> _______________________________________________
> 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