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

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 >>>> >>> >