From issues at jboss.org Fri Jul 24 10:20:03 2015 Content-Type: multipart/mixed; boundary="===============5123160448799254402==" MIME-Version: 1.0 From: Rogerio Liesenfeld (JIRA) To: cdi-dev at lists.jboss.org Subject: [cdi-dev] [JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects Date: Fri, 24 Jul 2015 10:20:03 -0400 Message-ID: In-Reply-To: JIRA.12579311.1437747419000@Atlassian.JIRA --===============5123160448799254402== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable [ https://issues.jboss.org/browse/CDI-552?page=3Dcom.atlassian.jira.pl= ugin.system.issuetabpanels:all-tabpanel ] Rogerio Liesenfeld updated CDI-552: ----------------------------------- Description: = The current CDI programming model is not friendly to object-oriented code o= r 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 *stat= eful*, short-lived, objects, while still having @Inject fields in it. I sho= uldn't be forced to have a stateless (non-OO) class (ie, a [Transaction Scr= ipt](http://martinfowler.com/eaaCatalog/transactionScript.html). 2) Most classes in a business app are not meant to be used as subclasses, i= e, 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, o= r item 17 in the book). 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 li= ke "can't be final", "can't have final instance fields", "cannot be instant= iated 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: MyBusinessService businessOp =3D new MyBusinessService(fieldFromUI1, fieldF= romUI2, listWithMoreDataFromUI); businessOp.performSomeBusinessOperation(otherArgs); String result1 =3D businessOp.getResultXyz(); List moreResultData =3D businessOp.getFinalData(); ... while having MyBusinessService be a CDI bean containing one or more @In= ject/@PersistenceContext fields (typically, an EntityManager and perhaps ot= her service beans). Without this ability, application developers are forced to create procedura= l Transation Scripts (stateless service class, which tend to have low cohes= ion). For a CDI implementation to do this, it will need to use the java.lang.inst= rument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, J= Mockit) 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/htm= l/ch08s08.html was: The current CDI programming model is not friendly to object-oriented code o= r 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 *stat= eful*, short-lived, objects, while still having @Inject fields in it. I sho= uldn't be forced to have a stateless (non-OO) class (ie, a Transaction Script). 2) Most classes in a business app are not meant to be used as subclasses, i= e, 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, o= r item 17 in the book). 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 li= ke "can't be final", "can't have final instance fields", "cannot be instant= iated 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: MyBusinessService businessOp =3D new MyBusinessService(fieldFromUI1, fieldF= romUI2, listWithMoreDataFromUI); businessOp.performSomeBusinessOperation(otherArgs); String result1 =3D businessOp.getResultXyz(); List moreResultData =3D businessOp.getFinalData(); ... while having MyBusinessService be a CDI bean containing one or more @In= ject/@PersistenceContext fields (typically, an EntityManager and perhaps ot= her service beans). Without this ability, application developers are forced to create procedura= l Transation Scripts (stateless service class, which tend to have low cohes= ion). For a CDI implementation to do this, it will need to use the java.lang.inst= rument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo, J= Mockit) 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/htm= l/ch08s08.html > 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 *st= ateful*, short-lived, objects, while still having @Inject fields in it. I s= houldn't be forced to have a stateless (non-OO) class (ie, a [Transaction S= cript](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 ma= ke them `final` (see http://lcsd05.cs.tamu.edu/slides/keynote.pdf, page 26,= or item 17 in the book). > 3) For a class to truly be a POJO, I must be able to make *full use* of t= he Java language when designing and implementing it; arbitrary constraints = like "can't be final", "can't have final instance fields", "cannot be insta= ntiated 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/C= DI backing bean for a web UI: > MyBusinessService businessOp =3D new MyBusinessService(fieldFromUI1, fiel= dFromUI2, listWithMoreDataFromUI); > businessOp.performSomeBusinessOperation(otherArgs); > String result1 =3D businessOp.getResultXyz(); > List moreResultData =3D businessOp.getFinalData(); > ... 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 procedu= ral Transation Scripts (stateless service class, which tend to have low coh= esion). > For a CDI implementation to do this, it will need to use the java.lang.in= strument API, like others tools (AspectJ, JBoss AOP, JBoss Byteman, JaCoCo,= JMockit) already do. > Also, for reference, the Spring framework already supports it for some ti= me: http://docs.spring.io/spring/docs/3.0.0.M3/spring-framework-reference/h= tml/ch08s08.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) --===============5123160448799254402==--