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

[Sven Linstaedt (JIRA)]

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

Sven Linstaedt commented on CDI-552:
------------------------------------

Most of theses requirements are already possible using some factory delegation:

In order to archive injection with "manually" programmatically provided arguments, I would create a dedicated factory, which is fully managed by CDI and 
* has all of {{MyBusinessService::new}} injected dependencies already injected via {{Instance<X>}}
* has a create method with all manually provided parameters, which
* creates are new MyBusinessService by invoking the beforementioned constructor with manually provided arguments and {{instance.get()}} provided dependencies
* "remembers" all via created dependencies in some map (in case of dependent scoped dependencies)
* use a {{InjectionTarget<MyBusinessService>}} and for injecting all remaining dependencies and calling it's {{@PostConstruct}} method, just as it is done in {{javax.enterprise.inject.spi.Unmanaged}}.

As the application is going to manage the the "bean's" lifecycle itself (via {{new}}) like for dependent scoped beans, it should also be responsible for destroying it explicitly (normally one would call some destroying method like {{AutoClosable}} and/or simply wait for the GC). So the factory should 
* have some destroy method for {{MyBusinessService}}
* having it's {{@PreDestroy}} method called via {{InjectionTarget<MyBusinessService>}} 
* having all of MyBusinessService created dependencies destroyed via {{Instance::destroy}}

In order to get AOP support you would need some class enhancement as mentioned by Rogerio, because decorators and interceptors are attached to the instance itself and not to some kind of proxy instance.

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