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

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 >