Dne 13.2.2018 v 13:13 arjan tijms napsal(a):
Hi,
When writing an alternative producer, e.g.
@Alternative
@Priority(500)
@ApplicationScoped
public class ApplicationInit {
@Produces
public HttpAuthenticationMechanism produce(BeanManager beanManager) {
return ...
}
}
You not rarely need the bean the producer is going to be an alternative
for. For instance to wrap it, or otherwise augment it, or perhaps to
take a few values from.
I think it could be a nice feature. Pls file a JIRA issue.
In order to get that bean, a bunch of quite verbose code is needed. I.e
I came up with:
HttpAuthenticationMechanism mechanism =
createRef(
beanManager.resolve(
This wouldn't work because BeanManager.resolve() attempts to resolve the
ambiguities thus eliminate all non-alternative beans.
beanManager.getBeans(HttpAuthenticationMechanism.class)
.stream()
.filter(e ->
!e.getBeanClass().equals(ApplicationInit.class))
.collect(toSet())),
beanManager);
And:
HttpAuthenticationMechanism createRef(Bean<?> bean, BeanManager
beanManager) {
return (HttpAuthenticationMechanism)
beanManager.getReference(
bean,
HttpAuthenticationMechanism.class,
beanManager.createCreationalContext(bean));
}
I wonder if it would not be a good idea to introduce something to get
that original bean more easily, i.e. just like a decorator and @Delegate.
E.g.
@Alternative
@Priority(500)
@ApplicationScoped
public class ApplicationInit {
@Produces
public HttpAuthenticationMechanism produce(BeanManager beanManager,
HttpAuthenticationMechanism original) {
This would not work - you would need to distinguish the original
injection point.
return ...
}
}
Or reuse the @Delegate (perhaps with the @Alternative annotation)
-1 This might be confusing.
@Alternative
@Priority(500)
@ApplicationScoped
public class ApplicationInit {
@Inject
@Delegate
@Alternative (?)
private HttpAuthenticationMechanism original;
@Produces
public HttpAuthenticationMechanism produce(BeanManager beanManager) {
return ...
}
}
Thoughts?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic