Re: [cdi-dev] Producer#dispose(T instance) and similar

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&gt; > To: Mark Struberg <struberg(a)yahoo.de>; Pete Muir <pmuir(a)redhat.com&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > 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&gt;: > >> 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&gt;: >> >>> 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&gt; >>>> To: Mark Struberg <struberg(a)yahoo.de&gt; >>>> Cc: Arne Limburg <arne.limburg(a)openknowledge.de>; cdi-dev >>>> <cdi-dev(a)lists.jboss.org&gt; >>>> 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&gt; >>>>>> To: Mark Struberg <struberg(a)yahoo.de&gt; >>>>>> Cc: Arne Limburg <arne.limburg(a)openknowledge.de>; > cdi-dev >>>> <cdi-dev(a)lists.jboss.org&gt; >>>>>> 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&gt; >>>>>>>> To: Arne Limburg > <arne.limburg(a)openknowledge.de&gt; >>>>>>>> Cc: Mark Struberg <struberg(a)yahoo.de>; > cdi-dev >>>>>> <cdi-dev(a)lists.jboss.org&gt; >>>>>>>> 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&gt;: >>>>>>>>> >>>>>>>>>> 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&gt; >>>>>>>>>>>> To: cdi-dev > <cdi-dev(a)lists.jboss.org&gt; >>>>>>>>>>>> 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 >