[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-552:
-------------------------------------
CDI provides a {{CDI.instance().select(MyBusinessService.class).get()}} to return an object with resolved injections.
By using {{new}}, the lifecycle scope is no longer controlled by the CDI container so I am not sure CDI implementations can do that.
> 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Rogerio Liesenfeld (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
Rogerio Liesenfeld updated CDI-552:
-----------------------------------
Description:
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/htm...
was:
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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
> 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Rogerio Liesenfeld (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
Rogerio Liesenfeld updated CDI-552:
-----------------------------------
Description:
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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
was:
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
> 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:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = 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 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Rogerio Liesenfeld (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
Rogerio Liesenfeld updated CDI-552:
-----------------------------------
Description:
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
was:
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
> 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 <a href="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 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:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = 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 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Rogerio Liesenfeld (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
Rogerio Liesenfeld updated CDI-552:
-----------------------------------
Description:
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
was:
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 <a href="http://martinfowler.com/eaaCatalog/transactionScript.html">Transaction Script</a>).
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
> 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 <a href="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 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:
> MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
> businessOp.performSomeBusinessOperation(otherArgs);
> String result1 = businessOp.getResultXyz();
> List<result> moreResultData = 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 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Rogerio Liesenfeld (JIRA)
Rogerio Liesenfeld created CDI-552:
--------------------------------------
Summary: 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 <a href="http://martinfowler.com/eaaCatalog/transactionScript.html">Transaction Script</a>).
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 <a href="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 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:
MyBusinessService businessOp = new MyBusinessService(fieldFromUI1, fieldFromUI2, listWithMoreDataFromUI);
businessOp.performSomeBusinessOperation(otherArgs);
String result1 = businessOp.getResultXyz();
List<result> moreResultData = 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 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-551) Easier access to InjectionPoint qualifiers.
by Chris Rankin (JIRA)
[ https://issues.jboss.org/browse/CDI-551?page=com.atlassian.jira.plugin.sy... ]
Chris Rankin updated CDI-551:
-----------------------------
Description:
I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.
I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that this is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.
A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:
{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
private static final long serialVersionUID = 1L;
public QualifierMap(Iterable<? extends Annotation> qualifiers) {
for (Annotation qualifier : qualifiers) {
put(qualifier.annotationType(), qualifier);
}
}
public <T extends Annotation> T get(Class<T> key) {
return (T) super.get(key);
}
}
{code}
However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:
{code:language=java}
public interface InjectionPoint {
...
boolean isQualifierPresent(Class<? extends Annotation> annotationType);
<T extends Annotation> T getQualifier(Class<T> annotationType);
....
}
{code}
was:
I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.
I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.
A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:
{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
private static final long serialVersionUID = 1L;
public QualifierMap(Iterable<? extends Annotation> qualifiers) {
for (Annotation qualifier : qualifiers) {
put(qualifier.annotationType(), qualifier);
}
}
public <T extends Annotation> T get(Class<T> key) {
return (T) super.get(key);
}
}
{code}
However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:
{code:language=java}
public interface InjectionPoint {
...
boolean isQualifierPresent(Class<? extends Annotation> annotationType);
<T extends Annotation> T getQualifier(Class<T> annotationType);
....
}
{code}
> Easier access to InjectionPoint qualifiers.
> -------------------------------------------
>
> Key: CDI-551
> URL: https://issues.jboss.org/browse/CDI-551
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Chris Rankin
>
> I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.
> I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that this is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.
> A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:
> {code:language=java}
> @SuppressWarnings("unchecked")
> public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
> private static final long serialVersionUID = 1L;
> public QualifierMap(Iterable<? extends Annotation> qualifiers) {
> for (Annotation qualifier : qualifiers) {
> put(qualifier.annotationType(), qualifier);
> }
> }
> public <T extends Annotation> T get(Class<T> key) {
> return (T) super.get(key);
> }
> }
> {code}
> However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:
> {code:language=java}
> public interface InjectionPoint {
> ...
> boolean isQualifierPresent(Class<? extends Annotation> annotationType);
>
> <T extends Annotation> T getQualifier(Class<T> annotationType);
> ....
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-551) Easier access to InjectionPoint qualifiers.
by Chris Rankin (JIRA)
Chris Rankin created CDI-551:
--------------------------------
Summary: Easier access to InjectionPoint qualifiers.
Key: CDI-551
URL: https://issues.jboss.org/browse/CDI-551
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Beans
Affects Versions: 1.2.Final
Reporter: Chris Rankin
I would like to extend {{javax.enterprise.inject.spi.InjectionPoint}} for easier analysis of both static and dynamic qualifiers.
I have previously used {{InjectionPoint.getAnnotated()}}, but have now realised that is not enough because it cannot include {{AnnotationLiteral}} qualifiers added via {{Instance.select(...)}}. The only reliable way to analyse _all_ of the qualifiers is currently via {{InjectionPoint.getQualifiers()}}, which unfortunately returns {{Set<Annotated>}}.
A {{Set<Annotated>>}} is not immediately useful to me; about the only thing that I can do with it is iterate over it every time. So I must convert it into something more like this first:
{code:language=java}
@SuppressWarnings("unchecked")
public class QualifierMap extends HashMap<Class<? extends Annotation>, Annotation> {
private static final long serialVersionUID = 1L;
public QualifierMap(Iterable<? extends Annotation> qualifiers) {
for (Annotation qualifier : qualifiers) {
put(qualifier.annotationType(), qualifier);
}
}
public <T extends Annotation> T get(Class<T> key) {
return (T) super.get(key);
}
}
{code}
However, it would be much _more_ convenient if {{InjectionPoint}} could export this functionality automatically instead:
{code:language=java}
public interface InjectionPoint {
...
boolean isQualifierPresent(Class<? extends Annotation> annotationType);
<T extends Annotation> T getQualifier(Class<T> annotationType);
....
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-550) Misleading AfterBeanDiscovery.addBean() description WRT interceptors and decorators
by Martin Kouba (JIRA)
Martin Kouba created CDI-550:
--------------------------------
Summary: Misleading AfterBeanDiscovery.addBean() description WRT interceptors and decorators
Key: CDI-550
URL: https://issues.jboss.org/browse/CDI-550
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 2.0-EDR1
Reporter: Martin Kouba
Priority: Minor
11.5.3. AfterBeanDiscovery event:
{quote}
* {{addBean()}} fires an event of type ProcessBean containing the given Bean and then registers the Bean with the container, thereby making it available for injection into other beans. The given Bean may implement Interceptor or Decorator.
{quote}
The wording is a bit misleading because interceptors and decorats are NOT available for injection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months
[JBoss JIRA] (CDI-549) Unnecessary statement in "8.1.2. Decorator delegate injection points" ?
by Tomas Remes (JIRA)
Tomas Remes created CDI-549:
-------------------------------
Summary: Unnecessary statement in "8.1.2. Decorator delegate injection points" ?
Key: CDI-549
URL: https://issues.jboss.org/browse/CDI-549
Project: CDI Specification Issues
Issue Type: Clarification
Components: Decorators
Affects Versions: 1.2.Final
Reporter: Tomas Remes
Priority: Minor
Decorators cannot declare observers, producers and disposers according to:
{quote}
Interceptors and decorators may not declare producer methods. If an interceptor or decorator has a method annotated @Produces , the container automatically detects the problem and treats it as a definition error.
{quote}
and
{quote}
Interceptors and decorators may not declare observer methods. If an interceptor or decorator has a method with a parameter annotated @Observes , the container automatically detects the problem
and treats it as a definition error.
{quote}
The question is whether following restriction (basically second sentence) is unnecessary because all conditions (in which this could happen) are already excluded in the above restrictions.
{quote}
The delegate injection point must be an injected field, initializer method parameter or bean constructor method parameter. If an injection point that is not an injected field, initializer method parameter or bean constructor method parameter is annotated @Delegate , the container
automatically detects the problem and treats it as a definition error.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 9 months