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

Mark Struberg struberg at yahoo.de
Tue Dec 4 09:20:33 EST 2012


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 at yahoo.de>
> To: cdi-dev <cdi-dev at lists.jboss.org>
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 


More information about the cdi-dev mailing list