Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
8 years, 11 months
O Captain! My Captain!
by Antoine Sabot-Durand
Hi Guys,
Just to inform you that Pete is stepping down his spec lead role on CDI as
he's going to take new responsibilities at Red Hat.
I think that we can thank him for the awesome work he did on CDI from the
beginning and wish him good luck for his new adventure in IT.
Goodbye Pete, and thanks for all the Beans ;)
Antoine
9 years, 5 months
[JBoss JIRA] (CDI-553) Chapter 10.5.3. Observer method invocation context should probably be in EE part
by Tomas Remes (JIRA)
Tomas Remes created CDI-553:
-------------------------------
Summary: Chapter 10.5.3. Observer method invocation context should probably be in EE part
Key: CDI-553
URL: https://issues.jboss.org/browse/CDI-553
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Tomas Remes
Chapter {{10.5.3. Observer method invocation context}} mainly speaks about transaction context and security context. AFAIK security context is a Java EE term and can be tested using EJBs.
So I think this chapter should be moved (or possibly split up) to the EE part of spec.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
No meeting today
by Antoine Sabot-Durand
Hi guys,
Won't be available today: my daughter will leave surgery at the same time.
Antoine
9 years, 5 months
[JBoss JIRA] (CDI-549) Unnecessary statement in "8.1.2. Decorator delegate injection points" ?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-549?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-549:
---------------------------------
My view is it does not harm to list them as we should not assume everyone who reads the specification know the full list of the injection points. As far as I know, some people just search particular phrases to verify whether the test application is valid or not.
> 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)
9 years, 5 months
[JBoss JIRA] (CDI-552) Add support for injection, decorators and interceptors on "new-ed" objects
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-552?page=com.atlassian.jira.plugin.sy... ]
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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 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 edited comment on CDI-552 at 7/24/15 11:03 AM:
------------------------------------------------------------------
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 include the necessary before/after calls.
Essentially, this is a wholly 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 avoiding 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.
was (Author: rliesenfeld2):
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 include the necessary before/after calls.
Essentially, this is a wholly 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 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 edited comment on CDI-552 at 7/24/15 11:03 AM:
------------------------------------------------------------------
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 include the necessary before/after calls.
Essentially, this is a wholly 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.
was (Author: rliesenfeld2):
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 include 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 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 edited comment on CDI-552 at 7/24/15 11:02 AM:
------------------------------------------------------------------
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 include 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.
was (Author: rliesenfeld2):
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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 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 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/htm...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
