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(a)openknowledge.de>
To: Mark Struberg <struberg(a)yahoo.de>; Pete Muir <pmuir(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)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(a)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(a)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(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: 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(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
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev