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

From reading the spec literally I must admit that Pete seems to be right

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 &gt;&lt;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 >>>>>> >>>>> >>> >