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
10 years, 1 month
[JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-508?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-508:
-----------------------------
Description:
The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans.
*3.1.1. Which Java classes are managed beans?* is confusing:
{quote}
A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:
* It is not a *non-static inner class*.
* It is a concrete class, or is annotated @Decorator.
* ...
{quote}
# A *top-level* Java class is never nested
# Term *non-static inner class* is inaccurate, static nested classes are not inner
# It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract...
was:
The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans.
*3.1.1. Which Java classes are managed beans?* is confusing:
{quote}
A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:
* It is not a *non-static inner class*.
{quote}
# a *top-level* Java class is never nested
# term *non-static inner class* is inaccurate, static nested classes are not inner
> Nested classes except for static nested classes should not be managed beans
> ---------------------------------------------------------------------------
>
> Key: CDI-508
> URL: https://issues.jboss.org/browse/CDI-508
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans.
> *3.1.1. Which Java classes are managed beans?* is confusing:
> {quote}
> A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:
> * It is not a *non-static inner class*.
> * It is a concrete class, or is annotated @Decorator.
> * ...
> {quote}
> # A *top-level* Java class is never nested
> # Term *non-static inner class* is inaccurate, static nested classes are not inner
> # It seems that *concrete class* is not defined in JLS, it should be probably replaced with something like non-abstract...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (CDI-508) Nested classes except for static nested classes should not be managed beans
by Martin Kouba (JIRA)
Martin Kouba created CDI-508:
--------------------------------
Summary: Nested classes except for static nested classes should not be managed beans
Key: CDI-508
URL: https://issues.jboss.org/browse/CDI-508
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
The spec should explicitly state that all nested classes (inner, anonymous, local) except for static nested classes are not managed beans.
*3.1.1. Which Java classes are managed beans?* is confusing:
{quote}
A *top-level* Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions:
* It is not a *non-static inner class*.
{quote}
# a *top-level* Java class is never nested
# term *non-static inner class* is inaccurate, static nested classes are not inner
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
Today's meeting agenda
by Antoine Sabot-Durand
Hi all
For today's meeting I'd like to close the async events chapter by deciding if we need to explicitly activate async on observers and decide if we support context or not in async operations.
Validation of java de bootstrap Api would be nice as well.
Antoine Sabot-Durand
11 years
[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-438:
---------------------------------
[[~antoinesabot-durand] This should definitely have "Fix version" 2.0 and please don't forget to remove the comments (as in CDI-385) on these classes as well.
> Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
> -------------------------------------------------------------------------------------
>
> Key: CDI-438
> URL: https://issues.jboss.org/browse/CDI-438
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
> The text:
> {quote}
> For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>.
> {quote}
> API:
> {code:java}
> /**
> * @param <T> The return type of the producer method
> * @param <X> The class of the bean declaring the producer method
> */
> public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
> }
> {code}
> The same applies to {{ProcessProducerField}}.
> TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
> It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-438:
-----------------------------
Description:
Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
The text:
{quote}
For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>.
{quote}
API:
{code:java}
/**
* @param <T> The return type of the producer method
* @param <X> The class of the bean declaring the producer method
*/
public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
}
{code}
The same applies to {{ProcessProducerField}}.
TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
was:
Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
The text:
{quote}
For a producer method with method **return type X** of a bean with **bean class T**, the container must raise an event of type ProcessProducerMethod<T, X>.
{quote}
API:
{code:java}
/**
* @param <T> The return type of the producer method
* @param <X> The class of the bean declaring the producer method
*/
public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
}
{code}
The same applies to {{ProcessProducerField}}.
TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
> Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events
> -------------------------------------------------------------------------------------
>
> Key: CDI-438
> URL: https://issues.jboss.org/browse/CDI-438
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event...
> The text:
> {quote}
> For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>.
> {quote}
> API:
> {code:java}
> /**
> * @param <T> The return type of the producer method
> * @param <X> The class of the bean declaring the producer method
> */
> public interface ProcessProducerMethod<T, X> extends ProcessBean<X> {
> }
> {code}
> The same applies to {{ProcessProducerField}}.
> TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time.
> It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
