]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
[~manovotn] didn't check but guess we do the same if there is a TCK. The point is more
that there is no technical reason to have this restriction so let's drop it in all
impl.
Could InterceptionFactory accept an interface as type parameter
---------------------------------------------------------------
Key: CDI-686
URL:
https://issues.jboss.org/browse/CDI-686
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 2.0 .Final
Reporter: Antoine Sabot-Durand
Assignee: Antoine Sabot-Durand
Fix For: 2.0 .Final
If you take this code:
{code:java}
@Produces
public List<Object> produceList(InterceptionFactory<List<Object>>
interceptionFactory) {
interceptionFactory.ignoreFinalMethods().configure().filterMethods((m) -> {
if (m.getJavaMember().getName().equals("add")
&& m.getJavaMember().getParameterCount() == 1) {
return true;
}
return false;
}).findFirst().get().add(Monitor.Literal.INSTANCE);
return interceptionFactory.createInterceptedInstance(new ArrayList<>());
}
{code}
Parameterized type for injected {{InterceptionFactory}} is an interface
{{List<Object>}}, so when calling {{configure()}}, user will work with an
{{AnnotatedTypeConfigurator<List<Object>>}} to apply interceptor binding.
In a standard interceptor usage, interceptor binding on interface are ignored (even if
they have {{@Inherited}} annotation), so doing it with {{InterceptionFactory}} could be
confusing for some user.