[cdi-dev] Producer#dispose(T instance) and similar
Arne Limburg
arne.limburg at openknowledge.de
Wed Dec 12 02:50:57 EST 2012
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