January 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

9 years, 3 months

4
8
0 / 0

[JBoss JIRA] (CDI-503) Properties injection from files to classes

by Nikos Ballas (JIRA)

[ https://issues.jboss.org/browse/CDI-503?page=com.atlassian.jira.plugin.sy... ] Nikos Ballas updated CDI-503: ----------------------------- Summary: Properties injection from files to classes (was: Properties injection from files to classes that are valid beans) > Properties injection from files to classes > ------------------------------------------ > > Key: CDI-503 > URL: https://issues.jboss.org/browse/CDI-503 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts, Packaging and Deployment > Reporter: Nikos Ballas > > I would like to be able to provide under META-INF folder my .properties file and have the the values automatically injected(loaded) into my bean using annotation injection. DeltaSpike offers something similar but with alot of tricky code.I would like to be able to do the following: > case 1: > public MyClass{ > @PropertiesInjection(file = "/path/to/file") > private Properties properties > } > case 2: > @PropertyPlaceholder(file = "path/to/file") > public MyClass { > @InjectProperty(name="property.name") > private String propertyName > > @PropertyPlaceholder(file = "path/to/other/file") > public void someMethod(){ > @InjectProperty(name = "other.property") > String propertyName; > endpoint = propertyName+port; > } > } > Again it should be stated that would be nice to be able to apply the @PropertyPlaceholder annotation either as classlevel annotation and being able to override the value if it's in method level with different parameters. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-503) Properties injection from files to classes that are valid beans

by Nikos Ballas (JIRA)

Nikos Ballas created CDI-503: -------------------------------- Summary: Properties injection from files to classes that are valid beans Key: CDI-503 URL: https://issues.jboss.org/browse/CDI-503 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts, Packaging and Deployment Reporter: Nikos Ballas I would like to be able to provide under META-INF folder my .properties file and have the the values automatically injected(loaded) into my bean using annotation injection. DeltaSpike offers something similar but with alot of tricky code.I would like to be able to do the following: case 1: public MyClass{ @PropertiesInjection(file = "/path/to/file") private Properties properties } case 2: @PropertyPlaceholder(file = "path/to/file") public MyClass { @InjectProperty(name="property.name") private String propertyName @PropertyPlaceholder(file = "path/to/other/file") public void someMethod(){ @InjectProperty(name = "other.property") String propertyName; endpoint = propertyName+port; } } Again it should be stated that would be nice to be able to apply the @PropertyPlaceholder annotation either as classlevel annotation and being able to override the value if it's in method level with different parameters. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-434) AfterTypeDiscovery javadoc outdated

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-434?page=com.atlassian.jira.plugin.sy... ] Martin Kouba reassigned CDI-434: -------------------------------- Assignee: (was: Martin Kouba) > AfterTypeDiscovery javadoc outdated > ----------------------------------- > > Key: CDI-434 > URL: https://issues.jboss.org/browse/CDI-434 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > {quote} > *getAlternatives()* returns the ordered list of enabled alternatives for the application. Alternatives enabled for a bean archive are not included in the list > {quote} > vs http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/AfterTypeDi... > The same applies to {{getInterceptors()}} and {{getDecorators()}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-502: ------------------------------------- Yes, clarification probably. > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Tomasz Krakowiak commented on CDI-502: -------------------------------------- {quote} An actual type is a type that is not a wildcard nor an unresolved type variable. There is therefore no rule in 5.2.4 where a wildcard would be considered on the bean type side. {quote} Thanks, now I understand. It would be nice if legal bean types would be the types you can instantiate in Java (That doesn't covers all types a variable can have(eg. `List<? extends Optional<?>>`), but covers types, like `List<Optional<?>>`). And assignability to be exactly the same what in Java is with the exception for raw generic types. I guess I could report feature request. {quote} Correct. Not sure why it is so. {quote} Should I report it as a clarification or bug? > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-502: ------------------------------------- {quote}But assuming that it doesn't exclude wildcard types I think that rule{quote} An actual type is a type that is not a wildcard nor an unresolved type variable. There is therefore no rule in 5.2.4 where a wildcard would be considered on the bean type side. {quote}If I understand correctly "5.2.4. Assignability of raw and parameterized types" (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#assignable_parameters) indicates that bean type List<Optional<Object>> is assignable to required type List<Optional<? extends Object>> (which are not assignable to each other in Java language and wildcards are allowed in required types).{quote} Correct. Not sure why it is so. > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Tomasz Krakowiak (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Tomasz Krakowiak commented on CDI-502: -------------------------------------- Thanks for quick reply, [~jozed]. I struggling to understand how. I can't find in "5.2.4. Assignability of raw and parameterized types" anything that would disallow it. I'm not sure what "actual type". But assuming that it doesn't exclude wildcard types I think that rule {quote} the required type parameter is a wildcard, the bean type parameter is an actual type and the actual type is assignable to the upper bound, if any, of the wildcard and assignable from the lower bound, if any, of the wildcard {quote} covers it. h6. A little off the topic - I think I found a bug there If I understand correctly "5.2.4. Assignability of raw and parameterized types" (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#assignable_parameters) indicates that bean type {{List<Optional<Object>>}} is assignable to required type {{List<Optional<? extends Object>>}} (which are not assignable to each other in Java language and wildcards are allowed in required types). > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-502: ------------------------------------- "Assignability of raw and parameterized types" rules which do not currently allow this usecase. That indirectly indicates that this scenario is not supported by the spec. If we want to change it we'll need to update the rules also. > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Tomasz Krakowiak (JIRA)

Tomasz Krakowiak created CDI-502: ------------------------------------ Summary: Clarify "contains" meaning in "Legal bean types" specification. Key: CDI-502 URL: https://issues.jboss.org/browse/CDI-502 Project: CDI Specification Issues Issue Type: Clarification Components: Beans, Inheritance and Specialization Reporter: Tomasz Krakowiak CDI 1.1, section 2.2.1. Legal bean types says: {quote} A parameterized type that contains a wildcard type parameter is not a legal bean type. {quote} Does it means direct containment or deep/recursive containment? I understand this is clearly illegal: {code} @Produces List<?> produceList(){ //... } {code} But, are those two bean definitions legal: {code} @Produces List<Optional<?>> produceList(){ //... } {code} {code} // Bean types: MyList, List<Optional<?>>, Object // or // Bean types: MyList, Object @Dependent MyList extends List<Optional<?>> { //... } {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2015