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(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Arne Limburg <arne.limburg(a)openknowledge.de>; cdi-dev
<cdi-dev(a)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(a)redhat.com>
>> To: Arne Limburg <arne.limburg(a)openknowledge.de>
>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev
<cdi-dev(a)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(a)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(a)yahoo.de>
>>>>>> To: cdi-dev <cdi-dev(a)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@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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>