[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
[~xdury] yes, the "final" limitation will only be bypassed if you add it in the list of proxyable final classes (in openwebbeans.properties), this will proxy the class in an unsafe mode (ignoring the associated limitations). This is not something recommanded but the first part (proxying interfaces) is supported and there is no real reason to not do it.
> 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, 10 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:
---------------------------------
With OWB (TomEE 8.0.0-SNAPSHOT), I get the following error:
{code}
org.apache.webbeans.exception.WebBeansDeploymentException: Intercepted Bean interface external.ExternalService must be proxyable
{code}
> 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, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
Oki, seems OWB does not break for that. Also the spec doesnt prevent it since in the example the type is the interface so this is what ends in the type closure list where inheritance is not relevant. So guess this is a weld bug at the end.
> 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, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-686:
-----------------------------------
[TCK|https://github.com/cdi-spec/cdi-tck/tree/master/impl/src/main/java/or...] is only testing {{InterceptionFactory}} with classes, not 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, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
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.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-686:
-----------------------------------
[~rmannibucau] does this scenario currently work with OWB?
ATM in Weld we require a subclass to be passed into {{InterceptionFactory}}.
Like I said, theoretically, you are going against spec metadata inheritance with that...
> 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, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-686:
----------------------------------------
Any blocker to impl the interface part in weld (4.) ? on OWB side there is no issue so I think it can hit the spec anytime soon since it does not break users.
> 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, 10 months
[JBoss JIRA] (CDI-686) Could InterceptionFactory accept an interface as type parameter
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-686:
-----------------------------------
So, the reason why {{InterceptionFactory}} doesn't work on interfaces is basically spec chapter [4. Inheritance and specialization|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#inheritance], which says:
bq. Type-level metadata is never inherited from interfaces implemented by a bean.
This means that adding the interceptor binding on interface won't affect the actual bean. Hence the interception would not work.
bq. If I declare InterceptionFactory<ExternalServiceImplementation> instead...
Well, here it's obviously because of proxyability requirements as stated in the [{{createInterceptedInstance()}} docs|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#interception_factory] - cannot work with {{final}} type. You could work around {{final}} methods with {{ignoreFinalMethods()}} switch though.
What you could do is probably use a proxyable class in between the interface and the implementation and base the interception on that. Could even be an abstract class I think.
> 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, 10 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:
---------------------------------
On my project, {{@Produces}} is used to integrate objects which are not CDI-aware (coming from other pure java libraries) with CDI beans as long as they provide an interface if they need to be proxied ({{@ApplicationScoped}}).
The only problem I had before CDI 2.0 was that it wasn't possible to apply {{@Interceptor}} on those objects.
I thought that {{InterceptionFactory}} would fix the problem but the fact that it can't be parameterized with an interface is very limiting.
My use-case is the following:
{code:java}
public interface ExternalService {
/* some methods */
}
/* This implementation is not a CDI-bean, it is final (cannot be proxied) and has no default constructor or @Injected constructor. */
public final class ExternalServiceImplementation implements ExternalService {
public ExternalServiceImplementation(/* some dependencies */) { ... }
/* methods implementations */
}
@ApplicationScoped
public class Integrator {
@Produces @ApplicationScoped
public ExternalService externalService(/* some dependencies */) {
return new ExternalServiceImplementation(/* some dependencies */);
// This works as a proxy is created from the interface, not the implementation's class
}
}
{code}
Now, if I want to add transaction management to my object, I would change my code to:
{code:java}
@ApplicationScoped
public class Integrator {
@Produces @ApplicationScoped
public ExternalService externalService(InterceptionFactory<ExternalService> factory, /* some dependencies */) {
factory.configure().add(new TransactionalLiteral());
return factory.createInterceptedInstance(new ExternalServiceImplementation(/* some dependencies */));
}
}
{code}
But this does not work with the following message (in Weld):
{code}
WELD-001711: InterceptionFactory is not supported on interfaces. Check InterceptionFactory<external.ExternalService>
{code}
If I declare InterceptionFactory<ExternalServiceImplementation> instead, I get the following error:
{code}
WELD-001437: Bean type class external.ExternalServiceImplementation is not proxyable because it is final
{code}
> 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, 10 months
[JBoss JIRA] (CDI-735) Multiple Java SE Containers
by Markus Karg (JIRA)
Markus Karg created CDI-735:
-------------------------------
Summary: Multiple Java SE Containers
Key: CDI-735
URL: https://issues.jboss.org/browse/CDI-735
Project: CDI Specification Issues
Issue Type: Clarification
Components: Java SE Integration
Affects Versions: 2.0 .Final
Reporter: Markus Karg
Priority: Critical
CDI 13.1 says: "_An implementation does not need to support multiple calls of SeContainerInitializer.initialize() method when the SeContainer is running._"
If a Java SE application wants to create distinct Containers containing beans from the same JAR library, this effectively means, it MUST create multiple initializers, but the initializers MAY share the same default ClassLoader, OR does that means that each initializer MUST be given a separate ClassLoader, OR does that mean that it is IMPOSSIBLE to create multiple SeContainers at the same time?
The answer to this question is crucial to the further adoption of CDI on Java SE, as applications need to product multiple containers, but do neither want to rely on proprietary features of particular implementations (like Weld) nor could add qualifiers to the source code in case of assembling multiple binary (closed-source) libraries into one single Java SE application. Example: Java SE boots JAX-RS (not Servlet, not EE server) with two distinct applications on different ports. Application A uses Version 1 of a Library, Application B uses Version 2. Version 1 and Version 2 are incompatible. Hence injection into A MUST NOT be Version 2, and injection into B MUST NOT be Version 1. The common bootstrap code which starts up Application A and B in JAX-RS MUST provide distinct containers on the same Java SE VM as Applications A and B are binary JARs (not source code), hence cannot get annotated.
But there is no guarantee in the CDI spec HOW EVERY CDI implementation will handle this case. So effectivey at time of writing such an application CANNOT be written. Hence a clarification is needed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months