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