[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-527 at 5/21/15 12:33 PM:
-------------------------------------------------------------
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API (and the final public method in question is not in that set of API methods)! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
was (Author: struberg):
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-527 at 5/21/15 12:32 PM:
-------------------------------------------------------------
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
was (Author: struberg):
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
F
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-527 at 5/21/15 12:31 PM:
-------------------------------------------------------------
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
F
was (Author: struberg):
No, rather the oposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
F
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
No, rather the oposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.
Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.
F
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
It seems we missed a point in CDIProvider enhancement
by Antoine Sabot-Durand
Hi all,
While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
While running in Java EE getCDI() retuns the current container which is fine since there’s only one, but what do we expect from it when running in SE?
I thought of 2 simple solutions for EDR1:
1) make getCDI() return the last CDI object initialized by the CDIProvider
2) Forbid getCDI() in SE
Of course there’s always the solution of moving the code outside CDIProvider, but it’s less simple…
Wdyt,
Antoine
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-527:
-------------------------------------
OK, so EJB does not allow it either, correct?
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
Re: [cdi-dev] F2F city and date choice
by Werner Keil
As London is not in the list, I guess the F2F would take place either
before or after DevoXX UK, but not then.
I voted on the two cities closest to where I expect to be for the next few
months. With enough time and notice, I guess I could also get to the other
two if selected in the end (or another city, as long as it's not too far;-)
Werner
On Thu, May 21, 2015 at 3:13 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Spring beans.xml (JJ Snyder)
> 2. Re: F2F city and date choice (Mark Struberg)
> 3. Re: F2F city and date choice (Antoine Sabot-Durand)
> 4. [JBoss JIRA] (CDI-10) Add ability to access a bean instance
> from a proxy (Martin Kouba (JIRA))
> 5. [JBoss JIRA] (CDI-527) allow proxying of classes with
> non-private final methods (Jozef Hartinger (JIRA))
> 6. [JBoss JIRA] (CDI-527) allow proxying of classes with
> non-private final methods (Romain Manni-Bucau (JIRA))
> 7. [JBoss JIRA] (CDI-527) allow proxying of classes with
> non-private final methods (Mark Struberg (JIRA))
> 8. [JBoss JIRA] (CDI-527) allow proxying of classes with
> non-private final methods (Mark Struberg (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 May 2015 13:32:42 -0400
> From: JJ Snyder <j.j.snyder(a)oracle.com>
> Subject: [cdi-dev] Spring beans.xml
> To: cdi-dev(a)lists.jboss.org
> Message-ID: <555CC53A.8080200(a)oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Does anyone know how to tell Spring to use a different file and not
> "beans.xml"?
>
> Thanks,
> JJ
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 20 May 2015 22:18:59 -0700
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] F2F city and date choice
> To: "antoine(a)sabot-durand.net" <antoine(a)sabot-durand.net>,
> "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <1432185539.62932.YahooMailIosMobile(a)web121605.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150520/892640eb/at...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 May 2015 05:24:56 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] F2F city and date choice
> To: Mark Struberg <struberg(a)yahoo.de>, "cdi-dev(a)lists.jboss.org"
> <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBQjpRqyR7M8t2dpjsHJ4TKwru0Zrmg+fj9=
> aeGr_00WJg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Done,
>
> Thorben and Mark P.. If you want to add a second choice you can do too. But
> let's try to keep it 2.
>
> Antoine
> Le jeu. 21 mai 2015 ? 07:19, Mark Struberg <struberg(a)yahoo.de> a ?crit :
>
> > Can you allow multi options? Would like to check Brno and Munich.
> >
> > Lg,
> > Strub
> >
> >
> > Gesendet von Yahoo Mail f?r iPad <https://yho.com/footer0>
> >
> > Um 20.05.2015 17:31:56 schrieb Antoine Sabot-Durand<'
> > antoine(a)sabot-durand.net'>:
> > Hi Guys,
> >
> > As we decided yesterday, I created a Doodle to choose the city of the
> > meeting. Keep in mind that this vote is non binding ;) as there are other
> > parameters on the Red Hat side.
> > Please vote here:
> >
> > http://doodle.com/v6kn89dfr6vev4as
> >
> >
> > Antoine Sabot-Durand
> > ???????????????
> > Twitter : @antoine_sd
> > CDI co-spec lead & eco-system development
> > Agorava tech lead
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150521/2e6856cd/at...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 May 2015 08:23:19 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean
> instance from a proxy
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12416142.1281270392000.23153.1432210999908(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys...
> ]
>
> Martin Kouba reopened CDI-10:
> -----------------------------
>
>
> I believe this issue is valid and should be reopened. Recently, we've run
> into problems with two integration scenarios where having this portable way
> to detect a client proxy and access the bean instance would allow to
> implement portable "workarounds".
>
> h3. Bean Validation
>
> The spec does not forbid the *field access strategy* to be used for
> normal-scoped CDI beans. However, this doesn't work because injectable
> references for normal-scoped beans are client proxies and not direct
> references to contextual instances. See also
> https://forum.hibernate.org/viewtopic.php?f=26&t=1039523.
>
> h3. JAX-RS
>
> Weld client proxies lose generic type information which screws up
> injection of generic params into RESTEasy resource methods. See also
> WELD-1539.
>
>
> > 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
> >
> > 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.3.15#6346)
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 May 2015 08:42:19 -0400 (EDT)
> From: "Jozef Hartinger (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
> with non-private final methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12572138.1432055089000.23228.1432212139513(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy...
> ]
>
> Jozef Hartinger commented on CDI-527:
> -------------------------------------
>
> {quote}EJB does allow this.{quote}
>
> Can you elaborate on how EJB allows that? Based on the following:
>
> {quote}Only private methods of the bean class and any superclasses except
> java.lang.Object
> may be declared final{quote}
>
> I interpret the EJB spec as explicitly prohibiting this.
>
> > 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
> > Fix For: 2.0 (discussion)
> >
> >
> > 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.3.15#6346)
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 May 2015 08:53:19 -0400 (EDT)
> From: "Romain Manni-Bucau (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
> with non-private final methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12572138.1432055089000.23301.1432212799527(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy...
> ]
>
> Romain Manni-Bucau commented on CDI-527:
> ----------------------------------------
>
> it does
>
> > 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
> > Fix For: 2.0 (discussion)
> >
> >
> > 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.3.15#6346)
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 May 2015 09:02:19 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
> with non-private final methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12572138.1432055089000.23310.1432213339810(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy...
> ]
>
> Mark Struberg commented on CDI-527:
> -----------------------------------
>
> I remember a discussion back then with Marina and Linda. And what what I
> remember the outcome was that it is depending on the term 'Business Method'
> where final is forbidden. And a 'Business Method' in EJBs must be public.
> See EJB spec 4.6.5.
>
> > 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
> > Fix For: 2.0 (discussion)
> >
> >
> > 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.3.15#6346)
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 21 May 2015 09:13:20 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
> with non-private final methods
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12572138.1432055089000.23393.1432214000064(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy...
> ]
>
> Mark Struberg commented on CDI-527:
> -----------------------------------
>
> [~jharting] I digged a bit deeper. Seems EJB-3.2 introduced this (non
> backward compat) restriction. But *only* for NIVs!
> Previously this restriction was only for 'Business Methods'. Which always
> have been only public methods (this is what is different 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
> > Fix For: 2.0 (discussion)
> >
> >
> > 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.3.15#6346)
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.
>
> End of cdi-dev Digest, Vol 54, Issue 18
> ***************************************
>
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
[~jharting] I digged a bit deeper. Seems EJB-3.2 introduced this (non backward compat) restriction. But *only* for NIVs!
Previously this restriction was only for 'Business Methods'. Which always have been only public methods (this is what is different 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-527:
-----------------------------------
I remember a discussion back then with Marina and Linda. And what what I remember the outcome was that it is depending on the term 'Business Method' where final is forbidden. And a 'Business Method' in EJBs must be public. See EJB spec 4.6.5.
> 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
> Fix For: 2.0 (discussion)
>
>
> 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.3.15#6346)
10 years, 6 months
