April 2015 - cdi-dev - Jboss List Archives

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, 10 months

4
8
0 / 0

Spec doc generation and work simplification

by Antoine Sabot-Durand

Hi all, I just brought simplification to spec generation (one maven module instead of 4) and added some tools to ease the work on spec writing. Just check spec/README.adoc

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-515: ------------------------------------- Affects Version/s: 1.2.Final > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-515: ------------------------------------- Fix Version/s: 2.0 (discussion) > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-518: ------------------------------------- Affects Version/s: 1.2.Final > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > • any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-518: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify boundaries of the ServletContext event > ---------------------------------------------- > > Key: CDI-518 > URL: https://issues.jboss.org/browse/CDI-518 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > {quote} > An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application > context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired > when the application is destroyed. The event payload is: > • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle > • any java.lang.Object for other types of application. > {quote} > Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-516: ------------------------------------- Fix Version/s: 2.0 (discussion) > Firing events with dynamic parameterized types > ---------------------------------------------- > > Key: CDI-516 > URL: https://issues.jboss.org/browse/CDI-516 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: > {quote} > If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. > If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. > {quote} > Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: > {quote} > If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. > {quote} > While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: > {code} > @Inject > Event<Object> event; > event.select(new TypeLiteral<String>() {}); > {code} > It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. > Yet, there are use cases where that need is valid, for example: > {code} > <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception { > // Represents the runtime type for T > Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; > String uri = endpointUri(type, ip.getQualifiers()); > if (context.hasEndpoint(uri) == null) { > // Work around to pass the dynamic type > TypeLiteral<T> literal = new TypeLiteral<T>() {}; > for (Field field : TypeLiteral.class.getDeclaredFields()) { > if (field.getType().equals(Type.class)) { > field.setAccessible(true); > field.set(literal, type); > break; > } > } > // Here we used the dynamic type > Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); > context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); > } > return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); > } > {code} > In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. > Another alternative would be to enrich the {{BeanManager}} SPI with the following method: > {code} > public void fireEvent(Object event, Type type, Annotation... qualifiers); > {code} > That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-516) Firing events with dynamic parameterized types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-516?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-516: ------------------------------------- Affects Version/s: 1.2.Final > Firing events with dynamic parameterized types > ---------------------------------------------- > > Key: CDI-516 > URL: https://issues.jboss.org/browse/CDI-516 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antonin Stefanutti > Fix For: 2.0 (discussion) > > > For the time being, either by using {{Event.select(...)}}, respectively {{BeanManager.fireEvent(...)}}, it is not possible to fire an event whose runtime type is a dynamic parameterized type, as specified in [The {{Event}} interface|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#event]: > {quote} > If the container is unable to resolve the parameterized type of the event object, it uses the specified type to infer the parameterized type of the event types. > If the runtime type of the event object contains an unresolvable type variable, an {{IllegalArgumentException}} is thrown. > {quote} > Respectively in [Firing an event|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_fire_event]: > {quote} > If the runtime type of the event object contains a type variable, an {{IllegalArgumentException}} is thrown. > {quote} > While, it is possible to pass a {{TypeLiteral}} to the {{Event.select(...)}} method, e.g.: > {code} > @Inject > Event<Object> event; > event.select(new TypeLiteral<String>() {}); > {code} > It is not possible to pass a type variable known at runtime as the {{TypeLiteral}} class relies on the declared type variable and does not permit to override that behavior as the {{TypeLiteral.getType()}} method is declared {{final}}. > Yet, there are use cases where that need is valid, for example: > {code} > <T> CdiEventEndpoint<T> cdiEventEndpoint(InjectionPoint ip, CamelContext context, @Any Event<Object> event) throws Exception { > // Represents the runtime type for T > Type type = ((ParameterizedType) ip.getType()).getActualTypeArguments()[0]; > String uri = endpointUri(type, ip.getQualifiers()); > if (context.hasEndpoint(uri) == null) { > // Work around to pass the dynamic type > TypeLiteral<T> literal = new TypeLiteral<T>() {}; > for (Field field : TypeLiteral.class.getDeclaredFields()) { > if (field.getType().equals(Type.class)) { > field.setAccessible(true); > field.set(literal, type); > break; > } > } > // Here we used the dynamic type > Event<T> typedEvent = event.select(literal, ip.getQualifiers().toArray(new Annotation[ip.getQualifiers().size()])); > context.addEndpoint(uri, new CdiEventEndpoint<>(typedEvent, uri, context)); > } > return CamelContextHelper.getMandatoryEndpoint(context, uri, CdiEventEndpoint.class); > } > {code} > In the example above, the {{TypeLiteral}} class could have a constructor taking the dynamic type as argument. > Another alternative would be to enrich the {{BeanManager}} SPI with the following method: > {code} > public void fireEvent(Object event, Type type, Annotation... qualifiers); > {code} > That use case is taken from the [CDI event Camel endpoint|https://github.com/astefanutti/camel-cdi/blob/84426570bcd7815eb9...] in the [Camel CDI extension|https://github.com/astefanutti/camel-cdi]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-519) Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-519?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-519: ------------------------------------------ what do you suggest? # to forbid this or, # to explicitly state that {{Instance<T>}} can be used to destroy any dependent scoped bean instance of T. In your example if we go for 1, there will be no solution to destroy the instance you requested thru {{CDI}} > Instance.destroy() cannot be used for dependent bean instances not created by the same Instance object > ------------------------------------------------------------------------------------------------------ > > Key: CDI-519 > URL: https://issues.jboss.org/browse/CDI-519 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > 5.6.1. The Instance interface: > {quote} > The method destroy() instructs the container to destroy the instance. The bean instance passed to destroy() should be *a dependent scoped bean instance*, or... > {quote} > I think this should be more obvious. E.g. this wouldn't work correctly even though it doesn't violate the spec: > {code:java} > @Dependent > class Bar { > } > class Foo { > @Inject > Instance<Bar> instance; > void ping() { > instance.destroy(CDI.current().select(Bar.class).get()); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-520) 3.6. Java EE components

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-520: ------------------------------------------ If you're interested by relations between CDI and EntityManager, you are reading the wrong section. Section 3.6 deals with Java Components like: * Servlet, * Interceptor, * JPA, Entity Listener, * etc... (see table EE5.1 in Java EE 7 spec to have the complete list) These components support injecting CDI beans but are not recommended to be injected or to define producers, disposers or observer methods. I agree that the sentence is not very clear. Regarding your needs, you have to study section [3.7 Resources|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#resources] since EntityManager is eligible to this notion of resources. As you can read in this part {quote} The container is not required to support resources with scope other than @Dependent. Portable applications should not define resources with any scope other than @Dependent. {quote} so you should try to put a scope on your produced `EntityManager`... What would be your use case anyway? > 3.6. Java EE components > ----------------------- > > Key: CDI-520 > URL: https://issues.jboss.org/browse/CDI-520 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.1.Final > Reporter: Martin Andersson > Fix For: TBD > > > I don't understand this text: > "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field." > More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest. > My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2015