From issues at jboss.org  Tue Dec  1 02:30:00 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 1 Dec 2015 02:30:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized
 disable a second bean?
In-Reply-To: <JIRA.12593965.1448378599000@Atlassian.JIRA>
References: <JIRA.12593965.1448378599000@Atlassian.JIRA>
	<JIRA.12593965.1448378599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593965.1448378599000.53051.1448955000243@Atlassian.JIRA>


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

Martin Kouba commented on CDI-574:
----------------------------------

Yes, application deployment fails with unsatisfied dependencies - see also the original description.

> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
>                 Key: CDI-574
>                 URL: https://issues.jboss.org/browse/CDI-574
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Inheritance and Specialization
>    Affects Versions: 1.2.Final
>         Environment: n/a
>            Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, ?Enabled and disabled beans?, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject at CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier  (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
>  beans.xml
>    <alternatives>
>         <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
>    </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR   ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
>   at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
>   at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Dec  1 02:38:00 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 1 Dec 2015 02:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized
 disable a second bean?
In-Reply-To: <JIRA.12593965.1448378599000@Atlassian.JIRA>
References: <JIRA.12593965.1448378599000@Atlassian.JIRA>
	<JIRA.12593965.1448378599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593965.1448378599000.53058.1448955480153@Atlassian.JIRA>


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

Martin Kouba edited comment on CDI-574 at 12/1/15 2:37 AM:
-----------------------------------------------------------

Yes, on Weld the deployment fails with unsatisfied dependencies - see also the original description.


was (Author: mkouba):
Yes, application deployment fails with unsatisfied dependencies - see also the original description.

> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
>                 Key: CDI-574
>                 URL: https://issues.jboss.org/browse/CDI-574
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Inheritance and Specialization
>    Affects Versions: 1.2.Final
>         Environment: n/a
>            Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, ?Enabled and disabled beans?, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject at CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier  (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
>  beans.xml
>    <alternatives>
>         <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
>    </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR   ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
>   at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
>   at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


From issues at jboss.org  Tue Dec  1 05:45:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 1 Dec 2015 05:45:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer
	methods
In-Reply-To: <JIRA.12578938.1437573301000@Atlassian.JIRA>
References: <JIRA.12578938.1437573301000@Atlassian.JIRA>
	<JIRA.12578938.1437573301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578938.1437573301000.53705.1448966700264@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-547:
-------------------------------------
      Component/s: Events
    Fix Version/s: 2.0-EDR2


> Resolving sync/async observer methods
> -------------------------------------
>
>                 Key: CDI-547
>                 URL: https://issues.jboss.org/browse/CDI-547
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Jozef Hartinger
>             Fix For: 2.0-EDR2
>
>
> There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods.
> With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec  1 05:45:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 1 Dec 2015 05:45:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer
	methods
In-Reply-To: <JIRA.12578938.1437573301000@Atlassian.JIRA>
References: <JIRA.12578938.1437573301000@Atlassian.JIRA>
	<JIRA.12578938.1437573301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578938.1437573301000.53709.1448966700347@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-547:
-------------------------------------
    Affects Version/s: 2.0-EDR1


> Resolving sync/async observer methods
> -------------------------------------
>
>                 Key: CDI-547
>                 URL: https://issues.jboss.org/browse/CDI-547
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Jozef Hartinger
>             Fix For: 2.0-EDR2
>
>
> There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods.
> With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec  1 05:46:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 1 Dec 2015 05:46:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer
	methods
In-Reply-To: <JIRA.12578938.1437573301000@Atlassian.JIRA>
References: <JIRA.12578938.1437573301000@Atlassian.JIRA>
	<JIRA.12578938.1437573301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578938.1437573301000.53713.1448966760312@Atlassian.JIRA>


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

Antoine Sabot-Durand closed CDI-547.
------------------------------------
      Assignee: Antoine Sabot-Durand
    Resolution: Done


Resolved by clarifying other topic around sync / async observers

> Resolving sync/async observer methods
> -------------------------------------
>
>                 Key: CDI-547
>                 URL: https://issues.jboss.org/browse/CDI-547
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Jozef Hartinger
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.EDR1/javax/enterprise/inject/spi/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-] method for resolving observer methods.
> With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Tue Dec  1 11:56:16 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 01 Dec 2015 16:56:16 +0000
Subject: [cdi-dev] Canceling meeting
Message-ID: <CABu-YBRnwfDkeE708D+QRPzXb4WeRfVPWdP2ojyaHKJYtBOFPQ@mail.gmail.com>

Hi guys,

I have. a personals emergency and have to leave. So he meeting today.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151201/25803473/attachment.html 

From issues at jboss.org  Tue Dec 15 03:59:00 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 15 Dec 2015 03:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.15228.1450169940463@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

I wrote down a summary of the problem and possible solutions for proxying with final fields:

Java8 introduced a few final methods to existing classes.
This now leads to a javax.enterprise.inject.UnproxyableResolutionException at bootstrap if you have a producer method or field for those classes.

EJB also seemingly allows this. 
But it's specced on a completely different level.
EJB disallows final 'business methods'.
That means that whenever you have an interface only those methods will get proxied.
The methods of the implementation do not matter at all.
With NIV all methods are 'business methods' and must be proxyable imo (can someone verify this?).

I personally like the non-proxyable rule.
It really prevents tons o user errors.
As you all know CDI heavily relies on subclassing proxies. 
Means we override all methods from the proxied type.
But we obviously cannot override (and thus proxy) static, private and final methods.
While static and private methods do not really matter, all non-private non-static final methods do.
The problem appears when people invoke such a final method on the proxy.
In that case they will just hit the proxy and not the Contextual Instance.
To prevent the user from making this error we throw the UnproxyableResolutionException at bootstrap.


We now have a few options to deal with that:

A.) no it's not a problem at all. 
 - We often got the report for ConcurrentHashMap. 
 But people can already just use the ConcurrentMap interface as return type in their producers.
 - Also the report that this only makes a problem since Java8 is plain wrong imo.
 ConcurrentHashMap has the following method since at least Java7:
 	final V put(K key, int hash, V value, boolean onlyIfAbsent)
 - There are a few situations where it hurts though.
 E.g. extending ConcurrentHashMap with own functionality. 
 This would require introducing an own interface for this new functionality.

B.) Generally allow proxying of beans with final methods.
 - I'm rather -1 for this.
 The current behaviour was introduced exactly because people made too many errors and blew up at runtime.
 Removing this rule would really make things worse.
 Because people might then add new final methods. 
 And if you call those then you will only hit the proxy class and not the Contextual Instance.
 
C.) Introduce an annotation to explicitly declare Beans to be proxyable
 - Something like @AllowProxying
 Can be applied to producer methods, producer fields and managed beans.
 - That would make it explicit for programmers that they leave the sunshine path.
 People will blow up with the UnproxyableResolutionException and can then decide whether they want to provide that bean anyway or not.
 - Con: Only the author of the Producer or managed bean knows that he added it. 
 Thus other users will first need to look at the producer to become aware.
 But that might not be so much of a problem in most cases as it's only a matter of JavaDoc.
 
D.) Introduce an exclude list for knowingly 'bad' classes.
 - We could e.g. introduce that all classes from java.* and javax.* are proxyable by definition.
 - Con: hard to know what's going on and why the code doesn't work if a user calls such a final method.
 

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 04:59:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 15 Dec 2015 04:59:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.15504.1450173540338@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

Think D is just not realistic enough to be reliable on the long term (+ better is the spec doesnt get 100 pages of whitelist/blackist ;))
C sounds overkill for this particular and precise need

I hesitate between A and B cause B gives the ability to just code "java" which is nice. Now I never saw an application seeing this as a real issue/blocker (means when it happens the reaction is: "ah? not allowed, ok let's do this other way") so A would work fine with a very low cost.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 05:04:00 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 15 Dec 2015 05:04:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.15533.1450173840599@Atlassian.JIRA>


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

Tomas Remes commented on CDI-527:
---------------------------------

Yes +1 for A. I consider C as a bit of overkill too. It seems to me that it would bring rather confusion than clarification. 

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 06:04:00 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Tue, 15 Dec 2015 06:04:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.16071.1450177440434@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------

I am thinking from customers' view. For legacy applications falling into this category, they suddenly stopped working with the UnproxyableResolutionException exception throwing at runtime. Sometimes it is not realistic to update the applications. We need to provide a way for the applications to continue working.

I think D is good and we can introduce a system property to disable this by default and only enable the support when the property is explicitly set.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 06:06:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 15 Dec 2015 06:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.16082.1450177560312@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

[~emilyj] never has really been supported on CDI side, JDK broke some API (in a more vicious way than this jira) but doesnt mean CDi has to do anything. Do you have an example of a broken application cause of *application* code (and not JVM)?

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 06:35:00 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 15 Dec 2015 06:35:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.16288.1450179300437@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

[~emilyj] Also remember that CDI-1.2 is only specified for Java7.  Also note that EJB doesn't support this neither for NIVs...
How would D look like in practice? System properties and excludes can be done in a non-portable way anyway. But adding system properties to any spec is in 99% a sign of a broken design.

-1 for B. Just added it for completeness ;)

We also could have another option
E.) introduce some class excludes via beans.xml

But that would have the same issues like D imo. 

Imo C is the most explicit and easiest for users to grasp. 

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 07:18:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Dec 2015 07:18:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch
 to ServiceLoader
In-Reply-To: <JIRA.12593878.1448360795000@Atlassian.JIRA>
References: <JIRA.12593878.1448360795000@Atlassian.JIRA>
	<JIRA.12593878.1448360795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593878.1448360795000.16538.1450181880166@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-573:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
>                 Key: CDI-573
>                 URL: https://issues.jboss.org/browse/CDI-573
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 07:29:00 2015
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 15 Dec 2015 07:29:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.16580.1450182540250@Atlassian.JIRA>


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

Matej Novotny commented on CDI-527:
-----------------------------------

+1 for A. As pointed out by [~rmannibucau], I cannot really imagine an application where this would be a blocker.

While C sounds tempting at first, I am afraid of the level of complexity it would bring into the application. Especially for anyone who isn't the original author of the code in question.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 09:03:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Dec 2015 09:03:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch
 to ServiceLoader
In-Reply-To: <JIRA.12593878.1448360795000@Atlassian.JIRA>
References: <JIRA.12593878.1448360795000@Atlassian.JIRA>
	<JIRA.12593878.1448360795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593878.1448360795000.17360.1450188180261@Atlassian.JIRA>


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

Work on CDI-573 started by Antoine Sabot-Durand.
------------------------------------------------
> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
>                 Key: CDI-573
>                 URL: https://issues.jboss.org/browse/CDI-573
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 11:44:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Dec 2015 11:44:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch
 to ServiceLoader
In-Reply-To: <JIRA.12593878.1448360795000@Atlassian.JIRA>
References: <JIRA.12593878.1448360795000@Atlassian.JIRA>
	<JIRA.12593878.1448360795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593878.1448360795000.18831.1450197840268@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-573:
-------------------------------------
    Fix Version/s: 2.0 (proposed)


> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
>                 Key: CDI-573
>                 URL: https://issues.jboss.org/browse/CDI-573
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 11:48:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Dec 2015 11:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch
 to ServiceLoader
In-Reply-To: <JIRA.12593878.1448360795000@Atlassian.JIRA>
References: <JIRA.12593878.1448360795000@Atlassian.JIRA>
	<JIRA.12593878.1448360795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593878.1448360795000.18882.1450198080883@Atlassian.JIRA>


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

Antoine Sabot-Durand commented on CDI-573:
------------------------------------------

PR sent.
Code was simplified relying on JDK ServiceLoader class.
We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method).

Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ?

> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
>                 Key: CDI-573
>                 URL: https://issues.jboss.org/browse/CDI-573
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 15 11:48:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Tue, 15 Dec 2015 11:48:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-573) Review code of CDI class to switch
 to ServiceLoader
In-Reply-To: <JIRA.12593878.1448360795000@Atlassian.JIRA>
References: <JIRA.12593878.1448360795000@Atlassian.JIRA>
	<JIRA.12593878.1448360795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593878.1448360795000.18883.1450198080902@Atlassian.JIRA>


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

Antoine Sabot-Durand edited comment on CDI-573 at 12/15/15 11:47 AM:
---------------------------------------------------------------------

PR sent.
Code was simplified relying on JDK {{ServiceLoader}} class.
We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method).

Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ?


was (Author: antoinesabot-durand):
PR sent.
Code was simplified relying on JDK ServiceLoader class.
We could simplify more since the only provider used is the first found (see {{configuredProvider}} initialization in {{getCDIProvider()}} method).

Question is, as we didn't had tests for this code, how can we make sure that the behavior stays the same ?

> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
>                 Key: CDI-573
>                 URL: https://issues.jboss.org/browse/CDI-573
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 03:27:00 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 16 Dec 2015 03:27:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend
	javax.interceptor.InvocationContext
In-Reply-To: <JIRA.12552000.1410537664000@Atlassian.JIRA>
References: <JIRA.12552000.1410537664000@Atlassian.JIRA>
	<JIRA.12552000.1410537664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552000.1410537664000.21428.1450254420262@Atlassian.JIRA>


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

Tomas Remes commented on CDI-468:
---------------------------------

Created https://java.net/jira/browse/INTERCEPTORS_SPEC-32

> Extend javax.interceptor.InvocationContext
> ------------------------------------------
>
>                 Key: CDI-468
>                 URL: https://issues.jboss.org/browse/CDI-468
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Arne Limburg
>
> Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly.
> I propose to extend the javax.interceptor.InvocationContext interface with a method
> public Annotation getInterceptorBinding() or
> public <A extends Annotation> A getInterceptorBinding(Class<A> type)
> The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 03:47:01 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 16 Dec 2015 03:47:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.21484.1450255621068@Atlassian.JIRA>


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

Martin Kouba commented on CDI-527:
----------------------------------

+1 for A
-1 for introducing a system property

>From the user point of view - creating a producer for a third-party class is always risky (and it's not only about final methods, consider for example passivation scopes). For now there are two workarounds for JDK's HashMap/ConcurrentHashMap and similar use-cases:
# use the Map/ConcurrentMap interface as the bean class field/return type - bean author
# inject the Map/ConcurrentMap interface - bean consumer (see also my comment https://issues.jboss.org/browse/CDI-527?focusedCommentId=13120531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13120531)

bq. We need to provide a way for the applications to continue working.
Emily, I understand your point. But I don't think it's a good solution to transfer responsibility to CDI.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 04:56:00 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 16 Dec 2015 04:56:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-566) Container lifecycle events and
 context initialization events are synchronous
In-Reply-To: <JIRA.12587960.1444220472000@Atlassian.JIRA>
References: <JIRA.12587960.1444220472000@Atlassian.JIRA>
	<JIRA.12587960.1444220472000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12587960.1444220472000.21681.1450259760053@Atlassian.JIRA>


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

Tomas Remes commented on CDI-566:
---------------------------------

https://github.com/cdi-spec/cdi/pull/268 - this is likely sufficient I think. With regarding to lifecycle events it is already mentioned in first paragraph in https://github.com/cdi-spec/cdi/blob/2.0-EDR2/spec/src/main/asciidoc/core/spi.asciidoc#container-lifecycle-events

> Container lifecycle events and context initialization events are synchronous
> ----------------------------------------------------------------------------
>
>                 Key: CDI-566
>                 URL: https://issues.jboss.org/browse/CDI-566
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> I believe this should be more explicit. Also portable extensions should be encouraged to fire sync events when a custom context is initialized, see also 6.7. Context management for built-in scopes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 08:30:00 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Wed, 16 Dec 2015 08:30:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting
 with CompletionStage definition
In-Reply-To: <JIRA.12578943.1437573706000@Atlassian.JIRA>
References: <JIRA.12578943.1437573706000@Atlassian.JIRA>
	<JIRA.12578943.1437573706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578943.1437573706000.23054.1450272600957@Atlassian.JIRA>


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

Tomas Remes commented on CDI-548:
---------------------------------

This could be marked as resolved since FireAsyncException has been removed. 

> FireAsyncException conflicting with CompletionStage definition
> --------------------------------------------------------------
>
>                 Key: CDI-548
>                 URL: https://issues.jboss.org/browse/CDI-548
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Jozef Hartinger
>
> CompletionStage documentation says:
> {quote}
> if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause.
> {quote}
> On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 09:49:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 16 Dec 2015 09:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-548) FireAsyncException conflicting
 with CompletionStage definition
In-Reply-To: <JIRA.12578943.1437573706000@Atlassian.JIRA>
References: <JIRA.12578943.1437573706000@Atlassian.JIRA>
	<JIRA.12578943.1437573706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578943.1437573706000.23723.1450277340479@Atlassian.JIRA>


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

Antoine Sabot-Durand closed CDI-548.
------------------------------------
    Resolution: Done


> FireAsyncException conflicting with CompletionStage definition
> --------------------------------------------------------------
>
>                 Key: CDI-548
>                 URL: https://issues.jboss.org/browse/CDI-548
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Jozef Hartinger
>
> CompletionStage documentation says:
> {quote}
> if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause.
> {quote}
> On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 16:30:00 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 16 Dec 2015 16:30:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.25821.1450301400360@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------

Option A is easy but it does not help the customers with legacy applications. It is not their fault in the first place. The JDK change is beyond their control. If we want to make CDI popular, we should help the customers who are stuck if they are unable to update their legacy applications. 

Option D: Support proxy on all java.x or javax... classes. Since the system property does not sell well, how about introduce a method setAllowProxyingOnUnProxyable(boolean allowProxying) on CDI.java? If not set, false is the default.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 16 16:38:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Wed, 16 Dec 2015 16:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.25851.1450301880360@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

[~emilyj] any new API doesn't solve your issue since the applications are by hypothesis "legacy".

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 04:38:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 17 Dec 2015 04:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-575) Add test for CDI class
In-Reply-To: <JIRA.12597003.1450345040000@Atlassian.JIRA>
References: <JIRA.12597003.1450345040000@Atlassian.JIRA>
	<JIRA.12597003.1450345040605@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597003.1450345040000.27002.1450345080547@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-575:
----------------------------------------

             Summary: Add test for CDI class
                 Key: CDI-575
                 URL: https://issues.jboss.org/browse/CDI-575
             Project: CDI Specification Issues
          Issue Type: Clarification
          Components: Concepts
    Affects Versions: 2.0-EDR1
            Reporter: Antoine Sabot-Durand


The class {{javax.enterprise.inject.spi.CDI}} is the entry point for CDI container, but we don't provide any test for it.
As we plan to change its underlying implementation in CDI-573, it seems important to provide a test to be sure that the new implement behaves the same that the current one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 04:38:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 17 Dec 2015 04:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-575) Add test for CDI class
In-Reply-To: <JIRA.12597003.1450345040000@Atlassian.JIRA>
References: <JIRA.12597003.1450345040000@Atlassian.JIRA>
	<JIRA.12597003.1450345040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597003.1450345040000.27008.1450345080695@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-575:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Add test for CDI class
> ----------------------
>
>                 Key: CDI-575
>                 URL: https://issues.jboss.org/browse/CDI-575
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The class {{javax.enterprise.inject.spi.CDI}} is the entry point for CDI container, but we don't provide any test for it.
> As we plan to change its underlying implementation in CDI-573, it seems important to provide a test to be sure that the new implement behaves the same that the current one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 04:38:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 17 Dec 2015 04:38:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-575) Add test for CDI class
In-Reply-To: <JIRA.12597003.1450345040000@Atlassian.JIRA>
References: <JIRA.12597003.1450345040000@Atlassian.JIRA>
	<JIRA.12597003.1450345040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597003.1450345040000.27007.1450345080676@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-575:
-------------------------------------
    Fix Version/s: 2.0-EDR2


> Add test for CDI class
> ----------------------
>
>                 Key: CDI-575
>                 URL: https://issues.jboss.org/browse/CDI-575
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The class {{javax.enterprise.inject.spi.CDI}} is the entry point for CDI container, but we don't provide any test for it.
> As we plan to change its underlying implementation in CDI-573, it seems important to provide a test to be sure that the new implement behaves the same that the current one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 05:00:00 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Thu, 17 Dec 2015 05:00:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.27185.1450346400634@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------

Romain, the new API is used by CDI integrators (e.g. application servers) to set whether they would like to support this proxying on nonproxyable classes. Weld/OWB should provide the capability of proxying the unproxyable java. or javax. classes.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 05:06:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Thu, 17 Dec 2015 05:06:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.27251.1450346760755@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

Think we should stay close to java there and don't abuse of bytecode generation since we can end up in a state were we break java (extending classes and proxying final method is already). Proxying types need a no-op constructor for instance even if protected and this one is far more a real constraint when coding than final methods IMHO so users already know what is the technical impl (and implied constraints) so staying aligned on java keeps things understandable I think.

More specifically on the new API: this proxying is not always possible for java.* cause some API are not "exposed enough" so it is a super risky hyposthesis and even if the new API is not used on producer code itself the user would need to flag it anyway so the portability of legacy applications is already not free and suppose you hit this issue, what's the fastest? Modifying your code with a Ctrl+R (replace) or checking the spec and implementation for a feature which is maybe not reliable?


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 05:24:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Thu, 17 Dec 2015 05:24:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-575) Add test for CDI class
In-Reply-To: <JIRA.12597003.1450345040000@Atlassian.JIRA>
References: <JIRA.12597003.1450345040000@Atlassian.JIRA>
	<JIRA.12597003.1450345040000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597003.1450345040000.27377.1450347840053@Atlassian.JIRA>


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

Work on CDI-575 started by Antoine Sabot-Durand.
------------------------------------------------
> Add test for CDI class
> ----------------------
>
>                 Key: CDI-575
>                 URL: https://issues.jboss.org/browse/CDI-575
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Concepts
>    Affects Versions: 2.0-EDR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The class {{javax.enterprise.inject.spi.CDI}} is the entry point for CDI container, but we don't provide any test for it.
> As we plan to change its underlying implementation in CDI-573, it seems important to provide a test to be sure that the new implement behaves the same that the current one.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Thu Dec 17 12:37:00 2015
From: issues at jboss.org (Jens Schumann (JIRA))
Date: Thu, 17 Dec 2015 12:37:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.31108.1450373820680@Atlassian.JIRA>


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

Jens Schumann commented on CDI-527:
-----------------------------------

The only situation where I have been running into this issue was integrating CDI in an existing framework, where the entry point to CDI should be as integrated as possible and therefore required extending a framework class with protected final methods. In other words: If you work with framework X you have to extend base class Y (e.g. a web framework action). To make most out of CDI I would love to have an CDI bean extending Y which failed due to the UnproxyableResolutionException. 

The biggest difference to what you discussed above is: I have to deal with lots of legacy code that should be migrated to a newer stack (slowly). Moving to CDI and CDI interceptors (\@Transactional) requires to work with 10+ years old code, that uses base classes and protected final methods a lot. I have never had an issue with java.* or javax.* being Unproxyable so far.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 04:56:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 18 Dec 2015 04:56:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-566) Container lifecycle events and
 context initialization events are synchronous
In-Reply-To: <JIRA.12587960.1444220472000@Atlassian.JIRA>
References: <JIRA.12587960.1444220472000@Atlassian.JIRA>
	<JIRA.12587960.1444220472000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12587960.1444220472000.32827.1450432560520@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-566:
-------------------------------------
    Fix Version/s: 2.0-EDR2


> Container lifecycle events and context initialization events are synchronous
> ----------------------------------------------------------------------------
>
>                 Key: CDI-566
>                 URL: https://issues.jboss.org/browse/CDI-566
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>             Fix For: 2.0-EDR2
>
>
> I believe this should be more explicit. Also portable extensions should be encouraged to fire sync events when a custom context is initialized, see also 6.7. Context management for built-in scopes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 05:00:01 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Fri, 18 Dec 2015 05:00:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.32858.1450432801011@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------


>>I have never had an issue with java.* or javax.* being Unproxyable so far.
I know a customer has hit this problem after moving up to Java8.

Some customers use third party libraries and they don't have source code, so they cannot easily update the code. We can easily say "go to the open source community....". The reality is that it takes time and the customers' applications are not functioning and they cannot operate their business. 

Someone somehow has to offer help. I think we can address this problem with some careful design.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 08:07:00 2015
From: issues at jboss.org (Libor Kramolis (JIRA))
Date: Fri, 18 Dec 2015 08:07:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean
 instance from a proxy
In-Reply-To: <JIRA.12416142.1281270392000@Atlassian.JIRA>
References: <JIRA.12416142.1281270392000@Atlassian.JIRA>
	<JIRA.12416142.1281270392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12416142.1281270392000.33961.1450444020916@Atlassian.JIRA>


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

Libor Kramolis commented on CDI-10:
-----------------------------------

*+1 for use case (1).*

I hope it will work transparently. It seams to me strange to check if some application class instance is proxy or not to get Annotation instances written on class I've injected. I know I could write utility method for my code (and hope it correctly detects proxies):

{code:java}
public static <A extends Annotation> A getAnnotationProxyReady(Class<?> clazz, Class<A> annotationClass) {
    final A annotation = clazz.getAnnotation(annotationClass);

    if (annotation == null
            && (clazz.isSynthetic())) { //OK, this is probably proxy
        return getAnnotationProxyReady(clazz.getSuperclass(), annotationClass);
    } else {
        return annotation;
    }
}
{code}

and now I can access annotation written on bean:

{code:java}
@Target({ TYPE, METHOD, FIELD })
@Retention(RUNTIME)
@Documented
public @interface MyAnnotation {
    String attr1();
    int attr2;
}

@MyAnnotation(attr1="aaa", attr2=42)
public class MyBean {
    //...
}

@Inject
private MyBean myBean;

public void methodA() throws NoSuchMethodException {
    MyAnnotation myAnn = getAnnotationProxyReady(myBean.getClass(), MyAnnotation.class);
    //use my bean annotations ...
}
{code}

But I can not expect 3rd party libraries support such approach. 3rd party libraries just works with objects and classes and its annotations. They don't what to care about any proxy objects or different proxy implementations to do their business.

Note: It works with Annotations annotated by {{@Inherited}} what is expected.

{code:java}
@Target({ TYPE, METHOD, FIELD })
@Retention(RUNTIME)
@Documented
@Inherited
public @interface MyAnnotation {
    String attr1();
    int attr2;
}
{code}

So I would like to vote for: The proxy bean contains same annotations as original class. And exactly that class not its super-classes.
Note: It is necessary to say that it already works for method annotations, see WELD-1131. So the issue remains just on class itself.


> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
>                 Key: CDI-10
>                 URL: https://issues.jboss.org/browse/CDI-10
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.0
>            Reporter: Stuart Douglas
>             Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. 
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 09:20:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 18 Dec 2015 09:20:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders
 API (BeanBuilder, etc...)
In-Reply-To: <JIRA.12584201.1441699379000@Atlassian.JIRA>
References: <JIRA.12584201.1441699379000@Atlassian.JIRA>
	<JIRA.12584201.1441699379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584201.1441699379000.34486.1450448400194@Atlassian.JIRA>


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

Antoine Sabot-Durand reassigned CDI-558:
----------------------------------------

    Assignee: Antoine Sabot-Durand


> Standardize the Meta-Data builders API (BeanBuilder, etc...)
> ------------------------------------------------------------
>
>                 Key: CDI-558
>                 URL: https://issues.jboss.org/browse/CDI-558
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration).
> * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html
> * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html
> * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 09:20:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 18 Dec 2015 09:20:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders
 API (BeanBuilder, etc...)
In-Reply-To: <JIRA.12584201.1441699379000@Atlassian.JIRA>
References: <JIRA.12584201.1441699379000@Atlassian.JIRA>
	<JIRA.12584201.1441699379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584201.1441699379000.34488.1450448400240@Atlassian.JIRA>


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

Antoine Sabot-Durand updated CDI-558:
-------------------------------------
    Fix Version/s: 2.0-EDR2
                       (was: 2.0 (discussion))


> Standardize the Meta-Data builders API (BeanBuilder, etc...)
> ------------------------------------------------------------
>
>                 Key: CDI-558
>                 URL: https://issues.jboss.org/browse/CDI-558
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration).
> * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html
> * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html
> * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 09:36:00 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 18 Dec 2015 09:36:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-558) Standardize the Meta-Data builders
 API (BeanBuilder, etc...)
In-Reply-To: <JIRA.12584201.1441699379000@Atlassian.JIRA>
References: <JIRA.12584201.1441699379000@Atlassian.JIRA>
	<JIRA.12584201.1441699379000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584201.1441699379000.34683.1450449360275@Atlassian.JIRA>


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

Work on CDI-558 started by Antoine Sabot-Durand.
------------------------------------------------
> Standardize the Meta-Data builders API (BeanBuilder, etc...)
> ------------------------------------------------------------
>
>                 Key: CDI-558
>                 URL: https://issues.jboss.org/browse/CDI-558
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR2
>
>
> The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspike/core/util/bean/BeanBuilder.html] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration).
> * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/BeanBuilder.html
> * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalAfterBeanDiscovery.html
> * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/extensions/custombeans/BuilderExtension.java]



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 13:45:01 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Fri, 18 Dec 2015 13:45:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-576) Provide an API to say a bean
 depends on another instance
In-Reply-To: <JIRA.12597313.1450464282000@Atlassian.JIRA>
References: <JIRA.12597313.1450464282000@Atlassian.JIRA>
	<JIRA.12597313.1450464282833@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597313.1450464282000.36145.1450464301006@Atlassian.JIRA>

Romain Manni-Bucau created CDI-576:
--------------------------------------

             Summary: Provide an API to say a bean depends on another instance
                 Key: CDI-576
                 URL: https://issues.jboss.org/browse/CDI-576
             Project: CDI Specification Issues
          Issue Type: Epic
            Reporter: Romain Manni-Bucau


Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with CDI but it can be more vicious and through several layers.

If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.

We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belongs to extensions) allowing to require this kind of eager initialization can be nice.

we would get something like

{code}
event.dependencyOn(bean1, bean2);
{code}

and it would be fired before after validation event.

The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 13:49:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Fri, 18 Dec 2015 13:49:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-576) Provide an API to say a bean
 depends on another instance
In-Reply-To: <JIRA.12597313.1450464282000@Atlassian.JIRA>
References: <JIRA.12597313.1450464282000@Atlassian.JIRA>
	<JIRA.12597313.1450464282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597313.1450464282000.36148.1450464540015@Atlassian.JIRA>


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

Romain Manni-Bucau updated CDI-576:
-----------------------------------
    Description: 
Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers.

If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.

We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice.

we would get something like

{code}
event.dependencyOn(bean1, bean2);
{code}

and it would be fired before after validation event.

The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.

  was:
Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with CDI but it can be more vicious and through several layers.

If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.

We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belongs to extensions) allowing to require this kind of eager initialization can be nice.

we would get something like

{code}
event.dependencyOn(bean1, bean2);
{code}

and it would be fired before after validation event.

The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.



> Provide an API to say a bean depends on another instance
> --------------------------------------------------------
>
>                 Key: CDI-576
>                 URL: https://issues.jboss.org/browse/CDI-576
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Romain Manni-Bucau
>
> Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers.
> If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.
> We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice.
> we would get something like
> {code}
> event.dependencyOn(bean1, bean2);
> {code}
> and it would be fired before after validation event.
> The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 15:27:00 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Fri, 18 Dec 2015 15:27:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-576) Provide an API to say a bean
 depends on another instance
In-Reply-To: <JIRA.12597313.1450464282000@Atlassian.JIRA>
References: <JIRA.12597313.1450464282000@Atlassian.JIRA>
	<JIRA.12597313.1450464282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597313.1450464282000.36388.1450470420070@Atlassian.JIRA>


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

Mark Struberg commented on CDI-576:
-----------------------------------

@DependsOn in EJB is SERIOUSLY broken in practice. Imo we don't like that in CDI. Just touch that stuff in @PostConstruct and be done. If you create a loop then it will blow up anyway.
I cannot see what problem this should solve.

> Provide an API to say a bean depends on another instance
> --------------------------------------------------------
>
>                 Key: CDI-576
>                 URL: https://issues.jboss.org/browse/CDI-576
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Romain Manni-Bucau
>
> Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers.
> If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.
> We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice.
> we would get something like
> {code}
> event.dependencyOn(bean1, bean2);
> {code}
> and it would be fired before after validation event.
> The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Fri Dec 18 17:13:00 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Fri, 18 Dec 2015 17:13:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-576) Provide an API to say a bean
 depends on another instance
In-Reply-To: <JIRA.12597313.1450464282000@Atlassian.JIRA>
References: <JIRA.12597313.1450464282000@Atlassian.JIRA>
	<JIRA.12597313.1450464282000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597313.1450464282000.36528.1450476780055@Atlassian.JIRA>


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

Romain Manni-Bucau commented on CDI-576:
----------------------------------------

[~struberg] this is what I said (on the broken side) but it still needs a solution. "just touch that stuff" DOESNT solve anything since you have to know an API you can touch for proxies which is not obvious + as explained in the description you can not be able to do it if it is in several sublayers (it is more common that we think and why @DependsOn wouldnt even work in 50% of cases).

See this very simplified case (jira pseudo-coding so please forget typo etc):

{code}
class InstanceManager {
  @Produces @ApplicationScoped MyInstance produce() { ... }
  void release(@Disposes MyInstance instance) {...}
}
{code}



{code}
class InstanceUsage1 {
  @Inject
  MyInstance instance;

  void start(@Observes @Initialized(AppScoped.class) Object start) {
    instance.doWork();
  }
}
{code}


{code}
@Startup
@Singleton // or any other start thing
class InstanceUsage2 {
  @Inject
  MyWorker worker;

  @PostConstruct
  void init() {
    worker.startJobs();
  }
}
{code}



{code}
class MyWorker {
  @Inject
  MyInstance instance;

  void doWork() {
    instance.doSomethingElse();
  }
}
{code}

This use case is : not orderable events (in previous samples the startup event) we need to be able to enforce dependencies to ensure the InstanceManager is started as expected at the very beginning.

You can touch MyInstance in InstanceUsage1 but likely not in InstanceUsage2 where it is also needed.

The case of startup is obvious and you can surely argue it is not 100% CDI - but it is real - but it is the same if you have a resource while would be hit later in the request/session/... and you need to validate it exists before starting the flow. Of course you can "touch" it but then if you mock it or specialize it your touching code can just be wrong and corrupt your application. Since we have the metadata in extensions I don't see any issue to ask for an eager instantiation there. Even adding constraints for such a feature (like scopes supporting it etc) is perfectly valid and fine but not having it makes some cases very hard to support IMHO.


> Provide an API to say a bean depends on another instance
> --------------------------------------------------------
>
>                 Key: CDI-576
>                 URL: https://issues.jboss.org/browse/CDI-576
>             Project: CDI Specification Issues
>          Issue Type: Epic
>            Reporter: Romain Manni-Bucau
>
> Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers.
> If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.
> We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice.
> we would get something like
> {code}
> event.dependencyOn(bean1, bean2);
> {code}
> and it would be fired before after validation event.
> The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From antoine at sabot-durand.net  Mon Dec 21 06:39:26 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 21 Dec 2015 11:39:26 +0000
Subject: [cdi-dev] Next meeting on Tuesday 5th January 2016
Message-ID: <CABu-YBRa1e2_ttCwHA9x1Bw8qEH75Y1d84RwviQQNy0NKRt5kQ@mail.gmail.com>

Hi All,


I'll be on PTO for Holliday season for the 2 next weeks.
For those who celebrate christmas: Merry Chtistmas !

For all see you next year!

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151221/a27d38ca/attachment.html 

From john.d.ament at gmail.com  Mon Dec 21 07:46:22 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 21 Dec 2015 12:46:22 +0000
Subject: [cdi-dev] Next meeting on Tuesday 5th January 2016
In-Reply-To: <CABu-YBRa1e2_ttCwHA9x1Bw8qEH75Y1d84RwviQQNy0NKRt5kQ@mail.gmail.com>
References: <CABu-YBRa1e2_ttCwHA9x1Bw8qEH75Y1d84RwviQQNy0NKRt5kQ@mail.gmail.com>
Message-ID: <CAOqetn8Ym9oTwW4vjgtcT_auC9YO9fb0xHJcp+dixcshSS+Gmg@mail.gmail.com>

Sounds good to me.  Merry Christmas & Happy New Year to all.

John

On Mon, Dec 21, 2015 at 6:39 AM Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi All,
>
>
> I'll be on PTO for Holliday season for the 2 next weeks.
> For those who celebrate christmas: Merry Chtistmas !
>
> For all see you next year!
>
> Antoine
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151221/4339f50d/attachment.html 

From issues at jboss.org  Mon Dec 21 12:39:00 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Mon, 21 Dec 2015 12:39:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.2966.1450719540311@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

[~french_c] Imo a perfectly valid use case. In the case you described only the option with the excludes or with the special Annotation would be possible.

[~emilyj]] Not sure about this. Most of this classes already have final protected methods as of Java7. Which class do you have in mind?

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Mon Dec 21 12:54:00 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 21 Dec 2015 12:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.3009.1450720440236@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------

>>Not sure about this. Most of this classes already have final protected methods as of Java7. Which class do you have in mind?
HashMap#initHashSeedAsNeeded, as mentioned in your description.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Tue Dec 22 15:15:01 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 22 Dec 2015 15:15:01 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.4564.1450815301206@Atlassian.JIRA>


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

Mark Struberg commented on CDI-527:
-----------------------------------

But this final method is already in HashMap as of Java7. This is nothing which only got introduced with Java8...

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)

From issues at jboss.org  Wed Dec 23 03:54:00 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 23 Dec 2015 03:54:00 -0500 (EST)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.5720.1450860840314@Atlassian.JIRA>


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

Emily Jiang commented on CDI-527:
---------------------------------

Sorry, typo... You were right this initHashSeedAsNeeded was introduced to jdk7. I meant say their app will be broken once they move up to java7.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>             Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)