From issues at jboss.org Fri Jul 24 10:18:02 2015
Content-Type: multipart/mixed; boundary="===============6468850835344324020=="
MIME-Version: 1.0
From: Rogerio Liesenfeld (JIRA) <issues at jboss.org>
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:18:01 -0400
Message-ID: <JIRA.12579311.1437747419000.148710.1437747481951@Atlassian.JIRA>
In-Reply-To: JIRA.12579311.1437747419000@Atlassian.JIRA

--===============6468850835344324020==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Rogerio Liesenfeld created CDI-552:
--------------------------------------

             Summary: Add support for injection, decorators and interceptor=
s 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 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 <a href=3D"http:=
//martinfowler.com/eaaCatalog/transactionScript.html">Transaction Script</a=
>).
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 <a href=3D"http://www.amazon.com/Effective-Java-2nd-Joshua=
-Bloch/dp/0321356683">book</a>).
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<result> 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



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

--===============6468850835344324020==--