[
https://issues.jboss.org/browse/CDI-178?page=com.atlassian.jira.plugin.sy...
]
Jozef Hartinger commented on CDI-178:
-------------------------------------
At the time I raised this issue the behavior seemed as a good aid for a problem I was
facing when developing an extension. However, I am not sure anymore this is a good idea.
For each bean or other component that the container may use at runtime, the container
provides an implementation of the InjectionTarget interface. This implementation is
capable of instantiating, injecting and disposing a component instance. Furthermore, the
implementation allows information about injection points of the component to be obtained.
An extension may observe the ProcessInjectionTarget and replace the InjectionTarget of a
component with a custom implementation.
What this issue aims to standardize is that an extension may simply wrap a
container-provided InjectionTarget instance (A) and only override the getInjectionPoints()
method in the wrapper (B). That should cause the container-provided InjectionTarget
instance (A) (which was replaced by B) to change its behavior to reflect (inject) the new
injection points.
An issue here is that if a container-provided InjectionTarget implementation (A) is
replaced by an extension-provided one (B), the container has no way of finding out whether
A is used anymore or not. Therefore, A would have to speculatively "reconfigure"
itself to reflect getInjectionPoints() of B even though A may not actually be used at all
(B may be a self-contained InjectionTarget implementation and not a wrapper with modified
injection points).
Furthermore, the general idea of a "decorated" InjectionTarget instance
(decorated in the sense of the decorator pattern, not CDI decorators) changing behavior
based on the decorator is IMHO wrong and counterintuitive.
Require container-provided Producer implementation to use
getInjectionPoints()
------------------------------------------------------------------------------
Key: CDI-178
URL:
https://issues.jboss.org/browse/CDI-178
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 1.0
Reporter: Jozef Hartinger
Assignee: Pete Muir
Priority: Minor
Fix For: 1.1.PRD
A CDI extension should be able to turn a field of a into a CDI injection point as easily
as by overriding the getInjectionPoints() method of the container-provided InjectionTarget
implementation e.g.:
{code}
event.setInjectionTarget(decorate(event.getInjectionTarget()));
...
protected <T> InjectionTarget<T> decorate(final InjectionTarget<T>
delegate)
{
return new ForwardingInjectionTarget<T>() {
@Override
public Set<InjectionPoint> getInjectionPoints() {
Set<InjectionPoint> injectionPoints = new
HashSet<InjectionPoint>();
injectionPoints.addAll(super.getInjectionPoints());
injectionPoints.addAll(); // additional injection points
return injectionPoints;
}
@Override
protected InjectionTarget<T> delegate() {
return delegate;
}
};
}
{code}
However, the spec does not require the container-provided InjectionTarget implementation
to make use of the getInjectionPoint() method when creating a new instance. As a result,
the approach above may or may not work.
Therefore, it is currently necessary for a portable extension to also provide an
implementation of at least the inject() method (for field injection points) and implement
the injection itself. This is problematic in 1.0 of the spec since a portable extension
does not necessarily have access to the BeanManager instance of the BDA where the
injection target is deployed, thus different visibility rules apply.
Clarify that the container-provided implementation of the Producer interface should use
the result of the getInjectionPoints() method as a source of information about the
injection points to inject.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira