[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ] Rogerio Liesenfeld edited comment on CDI-552 at 7/24/15 11:03 AM: ------------------------------------------------------------------ The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed. Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls. Essentially, this is a wholly different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoiding the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance. was (Author: rliesenfeld2): The CDI container can still manage objects created with {{new}}, provided the constructors of the class are instrumented (through a java.lang.instrument.ClassFileTransformer installed at container startup - several tools already do this kind of thing). The class file transformer would, basically, insert a call to a container method similar to BeanManager#resolve, at the end of every constructor in an eligible class. This would result in the @Inject/etc. fields being properly set in the bean instance that was just new-ed. Application of decorators and interceptors could be implemented in a similar way, by transforming the bytecode of methods in the bean class to include the necessary before/after calls. Essentially, this is a wholly different approach to implement a CDI container. Rather than creating a proxy class that implements an interface, or a proxy subclass, the original user classes would go through bytecode transformations. Beyond avoid the limitations in the current approach, this would also improve the user experience when using the Java debugger, since there would no longer be generated proxy objects or subclasses to get in the way. It would also, I believe, improve performance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)