back to the original topic.
The weird thing for me is that
* the Bean<T> has all the important information e.g the Scope, the Stereotypes, etc
* both Bean<T> and Producer<T> have getInjectionPoints()
* If the Producer<T> is intended to create the proxies, then we would store them
directly in the Contexts. But then you don't have access to private methods anymore if
the container has no info about proxy internas. Remember that the EJB and Interceptors
spec require _proxying_ (delegation) and not subclassing!
* Otoh if the Producer<T> creates the proxies and stores them 'anonymously'
in the CreationalContext, then all other mechanics which needs this info don't work.
Please note that e.g. interceptors on Decorators need to get 'moved out' of the
decorator and be executed before all other decorator calls.
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: Thursday, December 13, 2012 4:55 PM
Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar
On 12 Dec 2012, at 11:46, Mark Struberg wrote:
> 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.
+1
>
>
> 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.
Mark and I discussed this specific one on IRC. Interceptors and decorators are
not required to be supported for producer methods or fields. However it is not
disallowed either :-)
>
> 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
>>