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
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months
[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)
9 years, 10 months