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 and others do not have it. Problem here is that a Producer could probably get exchanged via a portable extension via ProcessProducer#setProducer(Producer) so it could be from a foreign source which must not know anything about container implementation details. What now about having an interceptor on @PreDestroy? 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. Another issue being InjectionTarget#postConstruct() only having the instance T as well. Now what about @PostConstruct interceptors as defined in the interceptors spec? 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? LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

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

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 >

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: Wednesday, December 5, 2012 10:32 PM Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar Why do they need to take creationalContext, that is what I am missing. On 5 Dec 2012, at 20:33, Mark Struberg wrote: > Oki, sounds ok so far. > > What about InjectionTarget<T> ? > > InjectionTarget#postConstruct(T instance) > InjectionTarget#preDestroy(T instance) > > > They don't have a CreationalContext parameter. Where do they take the interceptors? And of course there _are_ interceptors allowed for InjectionTargets imo. > That could only work if 'instance' is a proxy already, isn't? > > > 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 >>> >>

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 >

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

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

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 &gt;&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 >>>>>>> >>>>>> >>>> >> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

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 >

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

" A managed bean is a bean that is implemented by a Java class."

10.4 Observer methods An observer method is a non-abstract method of a managed bean class or session bean class

12.3. Bean discovery   The container automatically discovers managed beans (according to the rules of Section 3.1.1,

“Which Java classes are managed beans?”) and session beans in bean archives and searches the bean classes for producer methods, producer fields, disposer methods and observer methods.

From: Martin Kouba <mkouba(a)redhat.com&gt; To: cdi-dev(a)lists.jboss.org Cc: Sent: Wednesday, December 12, 2012 9:34 AM Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar In my opinion "Managed bean" != "Producer". It's a different kind of bean as stated in "Chapter 3. Programming model": The container provides built-in support for injection and contextual lifecycle management of the following kinds of bean: * Managed beans * Session beans * Producer methods and fields * Resources (Java EE resources, persistence contexts, persistence units, remote EJBs and web services) And of course every kind of bean results in a Bean<T>... M Dne 11.12.2012 18:58, Mark Struberg napsal(a): >  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 &gt;&gt;  &lt;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

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.

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.

My understanding of the spec is that an InjectionTarget is completely responsible for building and invoking interceptors and decorators.

From: Jozef Hartinger <jharting(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: Pete Muir <pmuir(a)redhat.com>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Monday, December 10, 2012 10:23 AM Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar My understanding of the spec is that an InjectionTarget is completely responsible for building and invoking interceptors and decorators. The produce() method can either return the target object (assuming there are no interceptors or decorators) or a proxy that handles interception. This is completely transparent to the container. The instance that the container retrieves from the produce() method is then passed to postConstruct(), preDestroy() and dispose() methods. Note that if the instance is a proxy it is a client proxy (creating client proxies is the container's job, not InjectionTarget's) but rather an interceptor/decorator enabling proxy which carries interceptor/decorator instances. Therefore, the CreationalContext is not necessary in those methods as the instance itself knows how to invoke interceptors/decorators. HTH, JH On 12/07/2012 10:56 PM, Mark Struberg wrote: >> 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. > I think that would end up being highly non-portable and we must revert this 'clarification' as it breaks a lot of stuff! > > Proxies are the core business of the cdi container! If we allow/force a pluggable Producer<T> to handle the interception proxying then this would not be possible without knowing implementation details of the respective container. This starts with the fact that we need to store the implicitly @Dependent scoped Interceptors and Decorators in our CreationalContexts but we do _not_ define an API to portably extract Interceptors and Decorators from them later. > > > Also this contradicts the need that some functionality like e.g. CDI events might be private methods. There is just no way to invoke a private method on a proxy whose internal structure you don't know. And doing the interceptors via subclassing instead of proxies would break both the EJB and the interceptors spec which define that only 'external' calls must get intercepted. > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Pete Muir <pmuir(a)redhat.com&gt; >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, December 4, 2012 5:46 PM >> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar >> >> 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

Right, I am not saying this is crystal clear in the spec. This is how I understand the spec. The spec only says: " If the class has interceptors, produce() is responsible for building the interceptors and decorators of the instance"

The extension that wraps/creates the InjectionTarget instance can have the BeanManager injected. I am used to passing the BeanManager reference to the InjectionTarget during creation of the InjectionTarget instance and keeping it within the instance.

Right, I am not saying this is crystal clear in the spec. This is how I understand the spec. The spec only says: " If the class has interceptors, produce() is responsible for building the interceptors and decorators of the instance"

The extension that wraps/creates the InjectionTarget instance can have the BeanManager injected. I am used to passing the BeanManager reference to the InjectionTarget during creation of the InjectionTarget instance and keeping it within the instance.

From: Jozef Hartinger <jharting(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: Pete Muir <pmuir(a)redhat.com>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Monday, December 10, 2012 1:47 PM Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar On 12/10/2012 12:58 PM, Mark Struberg wrote: >> Right, I am not saying this is crystal clear in the spec. This is how I >> understand the spec. The spec only says: " If the class has >> interceptors, produce() is responsible for building the interceptors and >> decorators of the instance" > Oh you are right, this is even in the CDI-1.0 spec already :/ > > > >> The extension that wraps/creates the InjectionTarget instance can have >> the BeanManager injected. I am used to passing the BeanManager reference >> to the InjectionTarget during creation of the InjectionTarget instance >> and keeping it within the instance. > Well, this option is only possible if the BeanManager doesn't change depending on the horizontal layer you are in. You remember your 1.a decision? Imo that might blast all those approaches, doesn't it? Yes, for this to work correctly one would need to use the appropriate BeanManager for the given bean archive which is tricky and not really portable ATM. What I've seen so far is passing the BeanManager instance that the extension gets, which works mostly but breaks if the deployment structure gets more complicated (ear) or if alternatives are used. > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Jozef Hartinger <jharting(a)redhat.com&gt; >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> Cc: Pete Muir <pmuir(a)redhat.com>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; >> Sent: Monday, December 10, 2012 11:00 AM >> Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar >> >> On 12/10/2012 10:33 AM, Mark Struberg wrote: >>>>   My understanding of the spec is that an InjectionTarget is completely >>>>   responsible for building and invoking interceptors and decorators. >>>   That only got added in CDI-1.0. In CDI-1.0 it was _not_ defined. >> Right, I am not saying this is crystal clear in the spec. This is how I >> understand the spec. The spec only says: " If the class has >> interceptors, produce() is responsible for building the interceptors and >> decorators of the instance" >>>   My point is that this is technically not possible for a _portable_ Producer >> and InjectionTarget to get it right! >>>   It would need to know exactly: >>>   * how the proxies work, ASF, Javassist, BCEL, etc >>>   * how to store the Interceptors and Decorators in the CreationalContext >>>   * how to _retrieve_ the Interceptors and Decorators our of the >> CreationalContext again! >> Right, an extension can either wrap an existing producer that handles >> interceptors/decorators or provide its own InjectionTarget. The latter >> option makes sense in situations where the extension knows that the >> produced instance does not support interception/decoration. Otherwise it >> is more convenient to use the former option IMHO. >>>   I don't think this can be done in a portable way. At least I found no >> solution so far... >>>   An easy example: The produce(CC) method only has a CreationalContext >> parameter but not a BeanManager! So how would you e.g. resolve an >> @ApplicationScoped bean which contains the producer method? >> The extension that wraps/creates the InjectionTarget instance can have >> the BeanManager injected. I am used to passing the BeanManager reference >> to the InjectionTarget during creation of the InjectionTarget instance >> and keeping it within the instance. >>> >>>   The only solution I can think about is to define that setProducer and >> setInjectionTarget must only be used to _wrap_ the existing ones. >>> >>>   LieGrue, >>>   strub >>> >>> >>> >>> >>>   ----- Original Message ----- >>>>   From: Jozef Hartinger <jharting(a)redhat.com&gt; >>>>   To: Mark Struberg <struberg(a)yahoo.de&gt; >>>>   Cc: Pete Muir <pmuir(a)redhat.com>; cdi-dev >> <cdi-dev(a)lists.jboss.org&gt; >>>>   Sent: Monday, December 10, 2012 10:23 AM >>>>   Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar >>>> >>>>   My understanding of the spec is that an InjectionTarget is completely >>>>   responsible for building and invoking interceptors and decorators. The >>>>   produce() method can either return the target object (assuming there >> are >>>>   no interceptors or decorators) or a proxy that handles interception. >>>>   This is completely transparent to the container. >>>> >>>>   The instance that the container retrieves from the produce() method is >>>>   then passed to postConstruct(), preDestroy() and dispose() methods. >> Note >>>>   that if the instance is a proxy it is a client proxy (creating client >>>>   proxies is the container's job, not InjectionTarget's) but >> rather an >>>>   interceptor/decorator enabling proxy which carries >> interceptor/decorator >>>>   instances. Therefore, the CreationalContext is not necessary in those >>>>   methods as the instance itself knows how to invoke >> interceptors/decorators. >>>>   HTH, >>>> >>>>   JH >>>> >>>>   On 12/07/2012 10:56 PM, Mark Struberg wrote: >>>>>>     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. >>>>>     I think that would end up being highly non-portable and we must >> revert this >>>>   'clarification' as it breaks a lot of stuff! >>>>>     Proxies are the core business of the cdi container! If we >> allow/force a >>>>   pluggable Producer<T> to handle the interception proxying then >> this would >>>>   not be possible without knowing implementation details of the >> respective >>>>   container. This starts with the fact that we need to store the >> implicitly >>>>   @Dependent scoped Interceptors and Decorators in our CreationalContexts >> but we >>>>   do _not_ define an API to portably extract Interceptors and Decorators >> from them >>>>   later. >>>>>     Also this contradicts the need that some functionality like e.g. >> CDI events >>>>   might be private methods. There is just no way to invoke a private >> method on a >>>>   proxy whose internal structure you don't know. And doing the >> interceptors >>>>   via subclassing instead of proxies would break both the EJB and the >> interceptors >>>>   spec which define that only 'external' calls must get >> intercepted. >>>>>     LieGrue, >>>>>     strub >>>>> >>>>> >>>>> >>>>>     ----- Original Message ----- >>>>>>     From: Pete Muir <pmuir(a)redhat.com&gt; >>>>>>     To: Mark Struberg <struberg(a)yahoo.de&gt; >>>>>>     Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>>>>     Sent: Tuesday, December 4, 2012 5:46 PM >>>>>>     Subject: Re: [cdi-dev] Producer#dispose(T instance) and >> similar >>>>>>     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

> 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. I think that would end up being highly non-portable and we must revert this 'clarification' as it breaks a lot of stuff!

Proxies are the core business of the cdi container! If we allow/force a pluggable Producer<T> to handle the interception proxying then this would not be possible without knowing implementation details of the respective container. This starts with the fact that we need to store the implicitly @Dependent scoped Interceptors and Decorators in our CreationalContexts but we do _not_ define an API to portably extract Interceptors and Decorators from them later. Also this contradicts the need that some functionality like e.g. CDI events might be private methods. There is just no way to invoke a private method on a proxy whose internal structure you don't know. And doing the interceptors via subclassing instead of proxies would break both the EJB and the interceptors spec which define that only 'external' calls must get intercepted. LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: Mark Struberg <struberg(a)yahoo.de&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Tuesday, December 4, 2012 5:46 PM > Subject: Re: [cdi-dev] Producer#dispose(T instance) and similar > > 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! >