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
[JBoss JIRA] (CDI-545) Clarify that observers can't be remote business method
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-545?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-545:
---------------------------------
https://github.com/cdi-spec/cdi/pull/262
> Clarify that observers can't be remote business method
> -------------------------------------------------------
>
> Key: CDI-545
> URL: https://issues.jboss.org/browse/CDI-545
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> In section 10.4 of 1.2 spec we have:
> {quote}
> If the bean is a session bean, the observer method must be either a business method of the EJB or a static method of the bean class.
> {quote}
> in 10.4.2 we also have:
> {quote}
> If a non-static method of a session bean class has a parameter annotated {{@Observes}}, and the method is not a business method of the EJB, the container automatically detects the problem and treats it as a definition error.
> {quote}
> This 2 assertions don't prevent an observer to be a business method of a remote client of an EJB. We should be more precise here and forbid this scenario.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-567) Investigate user data holding in instances
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-567?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-567:
----------------------------------------
DeltaSpike uses some thread local for transaction and data stuff. Idea is to allo to store meta information in bean themself. We would probably desire to have two kind of enrich-able storage:
- one on Bean (model meta)
- one on instances when possible (when proxied to make it simple) for instance related meta
> Investigate user data holding in instances
> ------------------------------------------
>
> Key: CDI-567
> URL: https://issues.jboss.org/browse/CDI-567
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> Need: attach some data to instances
> Solutions (a few I'm thinking about writing these lines):
> - allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical)
> - allow context to handle data associated with their instances (caricaturally: a Map<Instance, Data> would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself)
> - extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;))
> Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-567) Investigate user data holding in instances
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-567?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-567:
---------------------------------
Sorry but I don't understand much. I am not really sure what you would like to achieve. Can you elaborate please (some code example might be helpful)? Can you point me to some extension (as an example) which uses ThreadLocal?
> Investigate user data holding in instances
> ------------------------------------------
>
> Key: CDI-567
> URL: https://issues.jboss.org/browse/CDI-567
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> Need: attach some data to instances
> Solutions (a few I'm thinking about writing these lines):
> - allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical)
> - allow context to handle data associated with their instances (caricaturally: a Map<Instance, Data> would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself)
> - extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;))
> Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-567) Investigate user data holding in instances
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-567:
--------------------------------------
Summary: Investigate user data holding in instances
Key: CDI-567
URL: https://issues.jboss.org/browse/CDI-567
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Romain Manni-Bucau
Need: attach some data to instances
Solutions (a few I'm thinking about writing these lines):
- allow CDI extensions to register ClassFileTransformer (or a CDI interface) to modify the bytecode of classes (I like this one since it opens a lot of awesome doors - far more than what is needed for this task feature - and even to make CDI instances not CDI compliant ;) but it is very technical)
- allow context to handle data associated with their instances (caricaturally: a Map<Instance, Data> would be associated to the context and it would be accessible either from an event - sadly we cant reuse initialized/destroyed ones - or the context itself)
- extend all beans having a registered "DataEnricher" to be able to handle this and make it inherit from a new interface "DataGetSet" (the name is horrible but it is to share the idea ;))
Main goal is to get rid of all the ThreadLocals CDI extensions can need when writing not final applications (= make libraries writer's lifes easier) on one side and to make easier to associate a model to an instance on another side (=avoid to redo the same in all extensions).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
No meeting today
by Antoine Sabot-Durand
In JavaOne, I'll be in the middle of a talk during the meeting... See you
next week.
Antoine
9 years, 2 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-527:
----------------------------------
[~struberg] Yes, it is about bean types. But the validation requirement is clearly defined:
bq. A bean type must be proxyable if an injection point resolves to a bean... Otherwise, the container automatically detects the problem, and treats it as a deployment problem.
For extensions, EL, etc. - you get {{UnproxyableResolutionException}} at runtime. Also note that a contextual reference is not required to implement all bean types of the bean. Only the required bean type and all interfaces (see 6.5.3. Contextual reference for a bean).
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
[~tremes] I think this wording only got introduced pretty recently. Afaik it was not there in EJB-3.1. So I assume they 'fixed' it into the wrong direction. And I fear it's an illegal non-backward compatible change in the EJB spec...
[~mkouba] No, I think you are not right. Read the paragraph 3.15. It is all about unproxyable BEAN TYPES. Not the Injection Points, it is BEAN TYPES. got me?
Only looking at injection points would also trash Extensions, EL and dynamic resolving (BeanManager#getBean by name or type).
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-527:
---------------------------------
I am not sure I follow on this. On the NIV's it's explicitly stated in {{4.9.8 Session Bean’s No-Interface View}} that:
{quote}
Only private methods of the bean class and any superclasses except java.lang.Object
may be declared final.
{quote}
There is no problem from CDI point of view AFAIK. In the case of interface view types I can't see any problem as well because the proxy instance is created for the interface type (not impl) which has all methods public and not final. What's the reason for CDI to behave differently? In fact I think we can't supress EJB validations anyway.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-527:
----------------------------------
For the record - the spec only requires the injection points to be validated, or rather the required bean types to be proxyable. So for the HashMap from JDK7 a simple workaround would be to inject/use the Map interface.
-1 for introducing a new annotation - this wouldn't help for third-party bean classes, e.g. the JDK7's HashMap example.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
