[cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects

[Rogerio Liesenfeld (JIRA)]

    [ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092765#comment-13092765 ] 

Rogerio Liesenfeld commented on CDI-552:
----------------------------------------

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 incluide the necessary before/after calls.

Essentially, this is a wholy 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.

> Add support for injection, decorators and interceptors on "new-ed" objects
> --------------------------------------------------------------------------
>
>                 Key: CDI-552
>                 URL: https://issues.jboss.org/browse/CDI-552
>             Project: CDI Specification Issues
>          Issue Type: Epic
>          Components: Beans, Decorators, Interceptors, Resolution
>    Affects Versions: 2.0-EDR1
>            Reporter: Rogerio Liesenfeld
>
> The current CDI programming model is not friendly to object-oriented code or proper class design, and does not support true POJOs.
> With this I mean:
> 1) For object-oriented code, I need to be able to instantiate and use *stateful*, short-lived, objects, while still having @Inject fields in it. I shouldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Script|http://martinfowler.com/eaaCatalog/transactionScript.html]).
> 2) Most classes in a business app are not meant to be used as subclasses, ie, they are not designed for extension; therefore, I should be able to make them {{final}} (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26, or item 17 in the [book|http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683]).
> 3) For a class to truly be a POJO, I must be able to make *full use* of the Java language when designing and implementing it; arbitrary constraints like "can't be final", "can't have final instance fields", "cannot be instantiated directly", etc. prevent it from being a "plain-old" Java object.
> Specifically, what I want is to be able to write the following in a JSF/CDI backing bean for a web UI:
> {code}
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = businessOp.getFinalData();
> {code}
> ... while having MyBusinessService be a CDI bean containing one or more @Inject/@PersistenceContext fields (typically, an EntityManager and perhaps other service beans).
> Without this ability, application developers are forced to create procedural Transation Scripts (stateless service class, which tend to have low cohesion).
> For a CDI implementation to do this, it will need to use the java.lang.instrument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, JMockit) already do.
> Also, for reference, the Spring framework already supports it for some time: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/html/ch08s08.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)