From markus at headcrashing.eu  Sun Sep  2 07:58:34 2018
From: markus at headcrashing.eu (Markus KARG)
Date: Sun, 2 Sep 2018 13:58:34 +0200
Subject: [cdi-dev] Multiple Java SE Containers
Message-ID: <006201d442b4$49b80450$dd280cf0$@eu>

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?

 

Thanks for clarification!

-Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180902/ec3b2145/attachment-0001.html 

From issues at jboss.org  Mon Sep  3 03:16:00 2018
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 3 Sep 2018 03:16:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-734) Clarify whether
 SeContainerInitializer#disableDiscovery() also disables automatic CDI
 Extension pickup
In-Reply-To: <JIRA.12767755.1535958924000@Atlassian.JIRA>
References: <JIRA.12767755.1535958924000@Atlassian.JIRA>
	<JIRA.12767755.1535958924731@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12767755.1535958924000.76914.1535958960479@Atlassian.JIRA>

Mark Struberg created CDI-734:
---------------------------------

             Summary: Clarify whether SeContainerInitializer#disableDiscovery() also disables automatic CDI Extension pickup
                 Key: CDI-734
                 URL: https://issues.jboss.org/browse/CDI-734
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Portable Extensions
    Affects Versions: 2.0.SP1
            Reporter: Mark Struberg
            Priority: Minor


The wording in SeContainerInitializer is a bit ambiguous whether CDI Extensions should still automatically get detected if SeContainerInitializer#disableDiscovery() got called.
The spec just talks about "internal synthetic bean archive".
And the JavaDoc says "By default, the discovery is enabled so that all beans from all discovered bean archives are considered." So again also just beans.
Both wordings give the impression that CDI Extensions (which don't use scanning but java.util.ServiceLoader) might still work.

Otoh the JavaDoc contains the sentence "Moreover, it's also possible to disable the discovery completely so that only the "synthetic" bean archive is considered:" which contains "disable the discovery completely".
 
Both options are fine for me, but in hindsight of portability it might be wise to clarify it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From manovotn at redhat.com  Mon Sep  3 04:35:46 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Mon, 3 Sep 2018 04:35:46 -0400 (EDT)
Subject: [cdi-dev] Multiple Java SE Containers
In-Reply-To: <006201d442b4$49b80450$dd280cf0$@eu>
References: <006201d442b4$49b80450$dd280cf0$@eu>
Message-ID: <1993810574.9599414.1535963746490.JavaMail.zimbra@redhat.com>

Hi,

I would say that it basically means it is up to implementation.

For instance in Weld you can start new SE container with some ID which helps determine which SE container are you referring to.
CDI API is very bare in this regard and doesn't allow for such approach.
I vaguely recall some EG discussions about it being unclear whether multiple SE containers are actually a valid/sought after use case.
So the wording ended up like this and implementations can do as they please for now.

If you have a use case I think it would be good to raise a JIRA ticket and ask for clarification/expansion of API in this regard.

Matej

----- Original Message -----
> From: "Markus KARG" <markus at headcrashing.eu>
> To: cdi-dev at lists.jboss.org
> Sent: Sunday, September 2, 2018 1:58:34 PM
> Subject: [cdi-dev] Multiple Java SE Containers
> 
> 
> 
> 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?
> 
> 
> 
> Thanks for clarification!
> 
> -Markus
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.

From markus at headcrashing.eu  Mon Sep  3 06:39:41 2018
From: markus at headcrashing.eu (Markus KARG)
Date: Mon, 3 Sep 2018 12:39:41 +0200
Subject: [cdi-dev] Multiple Java SE Containers
In-Reply-To: <1993810574.9599414.1535963746490.JavaMail.zimbra@redhat.com>
References: <006201d442b4$49b80450$dd280cf0$@eu>
	<1993810574.9599414.1535963746490.JavaMail.zimbra@redhat.com>
Message-ID: <013701d44372$6eef3450$4ccd9cf0$@eu>

Thanks! See https://issues.jboss.org/browse/CDI-735 :-)
-Markus


-----Original Message-----
From: Matej Novotny [mailto:manovotn at redhat.com] 
Sent: Montag, 3. September 2018 10:36
To: Markus KARG
Cc: cdi-dev at lists.jboss.org
Subject: Re: [cdi-dev] Multiple Java SE Containers

Hi,

I would say that it basically means it is up to implementation.

For instance in Weld you can start new SE container with some ID which helps determine which SE container are you referring to.
CDI API is very bare in this regard and doesn't allow for such approach.
I vaguely recall some EG discussions about it being unclear whether multiple SE containers are actually a valid/sought after use case.
So the wording ended up like this and implementations can do as they please for now.

If you have a use case I think it would be good to raise a JIRA ticket and ask for clarification/expansion of API in this regard.

Matej

----- Original Message -----
> From: "Markus KARG" <markus at headcrashing.eu>
> To: cdi-dev at lists.jboss.org
> Sent: Sunday, September 2, 2018 1:58:34 PM
> Subject: [cdi-dev] Multiple Java SE Containers
> 
> 
> 
> 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?
> 
> 
> 
> Thanks for clarification!
> 
> -Markus
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.



From issues at jboss.org  Mon Sep  3 06:40:00 2018
From: issues at jboss.org (Markus Karg (JIRA))
Date: Mon, 3 Sep 2018 06:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-735) Multiple Java SE Containers
In-Reply-To: <JIRA.12767812.1535971154000@Atlassian.JIRA>
References: <JIRA.12767812.1535971154000@Atlassian.JIRA>
	<JIRA.12767812.1535971154644@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12767812.1535971154000.79422.1535971200492@Atlassian.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)

From issues at jboss.org  Wed Sep 12 08:13:01 2018
From: issues at jboss.org (Xavier Dury (JIRA))
Date: Wed, 12 Sep 2018 08:13:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.31899.1536754381827@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632340#comment-13632340 ] 

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)

From issues at jboss.org  Wed Sep 12 09:01:04 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Wed, 12 Sep 2018 09:01:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.32483.1536757264186@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632372#comment-13632372 ] 

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)

From issues at jboss.org  Wed Sep 12 09:05:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 12 Sep 2018 09:05:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.32601.1536757500980@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632379#comment-13632379 ] 

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)

From issues at jboss.org  Wed Sep 12 09:16:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Wed, 12 Sep 2018 09:16:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.32849.1536758160744@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632386#comment-13632386 ] 

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)

From issues at jboss.org  Wed Sep 12 09:41:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 12 Sep 2018 09:41:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.33034.1536759660552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632408#comment-13632408 ] 

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)

From issues at jboss.org  Wed Sep 12 10:03:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Wed, 12 Sep 2018 10:03:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.33357.1536760980199@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632438#comment-13632438 ] 

Matej Novotny commented on CDI-686:
-----------------------------------

[TCK|https://github.com/cdi-spec/cdi-tck/tree/master/impl/src/main/java/org/jboss/cdi/tck/tests/extensions/interceptionFactory] 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)

From issues at jboss.org  Wed Sep 12 10:07:02 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 12 Sep 2018 10:07:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.33393.1536761222156@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632441#comment-13632441 ] 

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)

From issues at jboss.org  Wed Sep 12 10:15:01 2018
From: issues at jboss.org (Xavier Dury (JIRA))
Date: Wed, 12 Sep 2018 10:15:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.33510.1536761701819@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632451#comment-13632451 ] 

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)

From issues at jboss.org  Wed Sep 12 10:28:00 2018
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 12 Sep 2018 10:28:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.33742.1536762480564@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632468#comment-13632468 ] 

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)

From issues at jboss.org  Wed Sep 12 10:52:01 2018
From: issues at jboss.org (Xavier Dury (JIRA))
Date: Wed, 12 Sep 2018 10:52:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.34196.1536763921438@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632503#comment-13632503 ] 

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/main/java/org/apache/webbeans/intercept/InterceptorResolutionService.java#L225]).

> 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)

From issues at jboss.org  Fri Sep 14 08:46:01 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 14 Sep 2018 08:46:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-695) Allow stereotypes to include
 priority annotations
In-Reply-To: <JIRA.12680312.1488813260000@Atlassian.JIRA>
References: <JIRA.12680312.1488813260000@Atlassian.JIRA>
	<JIRA.12680312.1488813260000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12680312.1488813260000.49502.1536929161551@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633647#comment-13633647 ] 

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)

From issues at jboss.org  Tue Sep 18 02:53:00 2018
From: issues at jboss.org (Xavier Dury (JIRA))
Date: Tue, 18 Sep 2018 02:53:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.62288.1537253580375@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634642#comment-13634642 ] 

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)

From issues at jboss.org  Tue Sep 18 03:48:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 18 Sep 2018 03:48:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.63058.1537256880362@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634667#comment-13634667 ] 

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 {{@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)

From issues at jboss.org  Tue Sep 18 03:49:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 18 Sep 2018 03:49:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-736) Observer resolution -
 assignability clarification
In-Reply-To: <JIRA.12770164.1537256913000@Atlassian.JIRA>
References: <JIRA.12770164.1537256913000@Atlassian.JIRA>
	<JIRA.12770164.1537256913697@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12770164.1537256913000.63068.1537256940847@Atlassian.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_assignability].

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_assignable_parameters], 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_assignability].



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Sep 18 03:50:00 2018
From: issues at jboss.org (Xavier Dury (JIRA))
Date: Tue, 18 Sep 2018 03:50:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-686) Could InterceptionFactory accept
 an interface as type parameter
In-Reply-To: <JIRA.12678171.1487697120000@Atlassian.JIRA>
References: <JIRA.12678171.1487697120000@Atlassian.JIRA>
	<JIRA.12678171.1487697120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678171.1487697120000.63107.1537257000815@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634642#comment-13634642 ] 

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)

From issues at jboss.org  Tue Sep 18 03:52:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 18 Sep 2018 03:52:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-736) Observer resolution -
 assignability clarification
In-Reply-To: <JIRA.12770164.1537256914000@Atlassian.JIRA>
References: <JIRA.12770164.1537256914000@Atlassian.JIRA>
	<JIRA.12770164.1537256914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12770164.1537256914000.63135.1537257120984@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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_assignability].
> 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_assignable_parameters], 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_assignability].



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Sep 18 03:56:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 18 Sep 2018 03:56:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-736) Observer resolution -
 assignability clarification
In-Reply-To: <JIRA.12770164.1537256914000@Atlassian.JIRA>
References: <JIRA.12770164.1537256914000@Atlassian.JIRA>
	<JIRA.12770164.1537256914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12770164.1537256914000.63152.1537257360149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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_assignability].

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_assignable_parameters], 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_assignability]. 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_assignability].

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_assignable_parameters], 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_assignability].



> 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_assignability].
> 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_assignable_parameters], 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_assignability]. 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)

From issues at jboss.org  Tue Sep 18 03:57:00 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 18 Sep 2018 03:57:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-736) Observer resolution -
 assignability clarification
In-Reply-To: <JIRA.12770164.1537256914000@Atlassian.JIRA>
References: <JIRA.12770164.1537256914000@Atlassian.JIRA>
	<JIRA.12770164.1537256914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12770164.1537256914000.63160.1537257420260@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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_assignability].

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_assignable_parameters], 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_assignability]. 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_assignability].

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_assignable_parameters], 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_assignability]. 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_assignability].
> 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_assignable_parameters], 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_assignability]. 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)

From issues at jboss.org  Wed Sep 26 07:53:00 2018
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 26 Sep 2018 07:53:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-736) Observer resolution -
 assignability clarification
In-Reply-To: <JIRA.12770164.1537256914000@Atlassian.JIRA>
References: <JIRA.12770164.1537256914000@Atlassian.JIRA>
	<JIRA.12770164.1537256914000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12770164.1537256914000.113540.1537962780859@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638727#comment-13638727 ] 

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_assignability].
> 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_assignable_parameters], 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_assignability]. 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)