[JBoss JIRA] (CDI-736) Observer resolution - assignability clarification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-736:
------------------------------------------
Agree with you [~manovotn]. Re-reading 10.3.1 we have rules to assign parametrized event type to raw observer but no rules for the other way around : raw event type to parameterized observer.
As you suggested we should follow assignability defined in [5.2.4. Assignability of raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters]:
{quote}A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the required type are either unbounded type variables or java.lang.Object.{quote}
Thus, sentence to add to 10.3.1 should be:
{quote}A raw event type is considered assignable to a parameterized observed event type if the raw types are identical and all type parameters of the required type are either unbounded type variables or java.lang.Object.{quote}
> Observer resolution - assignability clarification
> -------------------------------------------------
>
> Key: CDI-736
> URL: https://issues.jboss.org/browse/CDI-736
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Resolution
> Affects Versions: 2.0.SP1
> Reporter: Matej Novotny
> Fix For: 2.1 (Discussion)
>
>
> Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
> What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
> Here is a bit of code, we have following two classes:
> {code}
> public interface QualifiedEvent<T> {
> // some methods
> }
> public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
> // some method impls
> }
> {code}
> Here is observer code:
> {code}
> void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
> // stuff going on here...
> }
> {code}
> And your event type is:
> {code}
> new EventImpl(clazz);
> {code}
> In this scenario, the spec is IMO unclear on what should happen in this particular case.
> Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
> bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
> I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
> Side note - for the sample above to work, you would need to change the observed types to {{QualifiedEvent<?>}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-736) Observer resolution - assignability clarification
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny updated CDI-736:
------------------------------
Description:
Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
Here is a bit of code, we have following two classes:
{code}
public interface QualifiedEvent<T> {
// some methods
}
public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
// some method impls
}
{code}
Here is observer code:
{code}
void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
// stuff going on here...
}
{code}
And your event type is:
{code}
new EventImpl(clazz);
{code}
In this scenario, the spec is IMO unclear on what should happen in this particular case.
Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
Side note - for the sample above to work, you would need to change the observed types to {{QualifiedEvent<?>}}.
was:
Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
Here is a bit of code, we have following two classes:
{code}
public interface QualifiedEvent<T> {
// some methods
}
public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
// some method impls
}
{code}
Here is observer code:
{code}
void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
// stuff going on here...
}
{code}
And your event type is:
{code}
new EventImpl(clazz);
{code}
In this scenario, the spec is IMO unclear on what should happen in this particular case.
Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
> Observer resolution - assignability clarification
> -------------------------------------------------
>
> Key: CDI-736
> URL: https://issues.jboss.org/browse/CDI-736
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Resolution
> Affects Versions: 2.0.SP1
> Reporter: Matej Novotny
> Fix For: 2.1 (Discussion)
>
>
> Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
> What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
> Here is a bit of code, we have following two classes:
> {code}
> public interface QualifiedEvent<T> {
> // some methods
> }
> public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
> // some method impls
> }
> {code}
> Here is observer code:
> {code}
> void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
> // stuff going on here...
> }
> {code}
> And your event type is:
> {code}
> new EventImpl(clazz);
> {code}
> In this scenario, the spec is IMO unclear on what should happen in this particular case.
> Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
> bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
> I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
> Side note - for the sample above to work, you would need to change the observed types to {{QualifiedEvent<?>}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-736) Observer resolution - assignability clarification
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny updated CDI-736:
------------------------------
Description:
Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
Here is a bit of code, we have following two classes:
{code}
public interface QualifiedEvent<T> {
// some methods
}
public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
// some method impls
}
{code}
Here is observer code:
{code}
void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
// stuff going on here...
}
{code}
And your event type is:
{code}
new EventImpl(clazz);
{code}
In this scenario, the spec is IMO unclear on what should happen in this particular case.
Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
was:
Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
Here is a bit of code, we have following two classes:
{code}
public interface QualifiedEvent<T> {
// some methods
}
public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
// some method impls
}
{code}
Here is observer code:
{code}
void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
// stuff going on here...
}
{code}
And your event type is:
{code}
new EventImpl(clazz);
{code}
In this scenario, the spec is IMO unclear on what should happen in this particular case.
Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
> Observer resolution - assignability clarification
> -------------------------------------------------
>
> Key: CDI-736
> URL: https://issues.jboss.org/browse/CDI-736
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Resolution
> Affects Versions: 2.0.SP1
> Reporter: Matej Novotny
> Fix For: 2.1 (Discussion)
>
>
> Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
> What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
> Here is a bit of code, we have following two classes:
> {code}
> public interface QualifiedEvent<T> {
> // some methods
> }
> public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
> // some method impls
> }
> {code}
> Here is observer code:
> {code}
> void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
> // stuff going on here...
> }
> {code}
> And your event type is:
> {code}
> new EventImpl(clazz);
> {code}
> In this scenario, the spec is IMO unclear on what should happen in this particular case.
> Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
> bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
> I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...]. That way the spec will behave coherently and *the above observer/event assignability should not work*.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-736) Observer resolution - assignability clarification
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-736:
-----------------------------
Fix Version/s: 2.1 (Discussion)
> Observer resolution - assignability clarification
> -------------------------------------------------
>
> Key: CDI-736
> URL: https://issues.jboss.org/browse/CDI-736
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Resolution
> Affects Versions: 2.0.SP1
> Reporter: Matej Novotny
> Fix For: 2.1 (Discussion)
>
>
> Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
> What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
> Here is a bit of code, we have following two classes:
> {code}
> public interface QualifiedEvent<T> {
> // some methods
> }
> public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
> // some method impls
> }
> {code}
> Here is observer code:
> {code}
> void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
> // stuff going on here...
> }
> {code}
> And your event type is:
> {code}
> new EventImpl(clazz);
> {code}
> In this scenario, the spec is IMO unclear on what should happen in this particular case.
> Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
> bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
> I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Xavier Dury (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Xavier Dury edited comment on CDI-686 at 9/18/18 3:49 AM:
----------------------------------------------------------
Workaround:
{code:java}
public interface MyService { ... }
public abstract class MyAbstractService implements MyService {} // purely abstract
public final class MyServiceImpl extends MyAbstractService { ... }
@Produces
@ApplicationScoped
public MyService myService(InterceptionFactory<MyAbstractService> factory) {
factory.configure().add(new AnnotationLiteral<Transactional>() {});
return factory.createInterceptedInstance(new MyServiceImpl(...));
}
{code}
It's a bit ridiculous (and you lose your one-shot at inheritance) but it demonstrates that if it works with a purely abstract class, there's no solid reason why it couldn't work with interfaces.
was (Author: xdury):
Workaround:
{code:java}
public interface MyService { ... }
public abstract class MyAbstractService implements MyService {} // purely abstract
public final class MyServiceImpl extends MyAbstractService { ... }
@Produces
@ApplicationScoped
public MyService myService(InterceptionFactory<MyAbstractService> factory) {
factory.configure().add(new AnnotationLiteral<Transactional>() {});
return factory.createInterceptedInstance(new MyServiceImpl(...));
}
{code}
It's a bit ridiculous (and you lose your own-shot at inheritance) but it demonstrates that if it works with a purely abstract class, there's no solid reason why it couldn't work with interfaces.
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-736) Observer resolution - assignability clarification
by Matej Novotny (JIRA)
Matej Novotny created CDI-736:
---------------------------------
Summary: Observer resolution - assignability clarification
Key: CDI-736
URL: https://issues.jboss.org/browse/CDI-736
Project: CDI Specification Issues
Issue Type: Clarification
Components: Resolution
Affects Versions: 2.0.SP1
Reporter: Matej Novotny
Recently we came up across an observer resolution issue which concerns [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
What happens when you are trying to assign a non-parameterized subclass to a parameterized superclass?
Here is a bit of code, we have following two classes:
{code}
public interface QualifiedEvent<T> {
// some methods
}
public class EventImpl implements QualifiedEvent { //NOTE - implements raw type
// some method impls
}
{code}
Here is observer code:
{code}
void listenForChildEvent(@Observes QualifiedEvent<Bar> foo) {
// stuff going on here...
}
{code}
And your event type is:
{code}
new EventImpl(clazz);
{code}
In this scenario, the spec is IMO unclear on what should happen in this particular case.
Looking at other parts of spec, we already have this covered in, for instance, [delegate injection point assignability|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#delegate_a...], where it says:
bq. A raw bean type is considered assignable to a parameterized delegate type if the raw types are identical and all type parameters of the delegate type are either unbounded type variables or java.lang.Object.
I think we should add a similar sentence to [10.3.1. Assignability of type variables, raw and parameterized types|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#observers_assignab...].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-686:
----------------------------------
I'm still a bit reluctant to make it possible to add interceptor bindings to interfaces. This would be a big change. And if we say that it's only allowed for {{InterceptionFactory}} then users would ask why not for other use cases? So we would probably have to modify the inheritance rules. BTW it seems that {{(a)javax.interceptor.Interceptors}} can also be applied to a target class or to a superclass of the target class.
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Xavier Dury (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Xavier Dury commented on CDI-686:
---------------------------------
Workaround:
{code:java}
public interface MyService { ... }
public abstract class MyAbstractService implements MyService {} // purely abstract
public final class MyServiceImpl extends MyAbstractService { ... }
@Produces
@ApplicationScoped
public MyService myService(InterceptionFactory<MyAbstractService> factory) {
factory.configure().add(new AnnotationLiteral<Transactional>() {});
return factory.createInterceptedInstance(new MyServiceImpl(...));
}
{code}
It's a bit ridiculous (and you lose your own-shot at inheritance) but it demonstrates that if it works with a purely abstract class, there's no solid reason why it couldn't work with interfaces.
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-695) Allow stereotypes to include priority annotations
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-695?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-695:
----------------------------------
I also think this could be useful. And use case? I can imagine a stereotype used in testing:
{code:java}
@Alternative
@SuperCoolInterceptorBinding
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface TestReplacement {}
@Priority(1)
@TestReplacement
class TestFoo extends Foo {
}
{code}
could be simply replaced with:
{code:java}
@Alternative
@Priority(1)
@SuperCoolInterceptorBinding
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface TestReplacement {}
@TestReplacement
class TestFoo extends Foo {
}
{code}
However, note that this would require a change in commons annotations - the {{@Priority}} target is currently {{@Target(value={*TYPE,PARAMETER*})}}.
> Allow stereotypes to include priority annotations
> -------------------------------------------------
>
> Key: CDI-695
> URL: https://issues.jboss.org/browse/CDI-695
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: John Ament
>
> Stereotypes can include things like Alternative. However, there is no mention as to whether or not Priority can be included in the stereotype definition. I feel it would be useful to be included.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Xavier Dury (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Xavier Dury commented on CDI-686:
---------------------------------
[~rmannibucau] If OWB {{InterceptorResolutionService}} could be patched to consider interfaces as proxyable, that would be great and would prove it is doable (actually, it deems them as not proxyable because no appropriate constructor can be [found|https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src...]).
> 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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 7 months