April 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-362: ------------------------------------- I was trying to emphasize non-public as a public final method would be an error detected by the EJB container nevertheless you are right, it should be "non-public non-private final methods on a session bean with bean class local view". > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-362: ----------------------------------- jozef, guess you meant 'non-private final methods', right? > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-362: ------------------------------------- I find this scary as a user may be doing this accidentally and they may not realize the mistake until runtime. Even at runtime the methods would be invoked on the client proxy instance so the methods may happen to seem to be working and not cause a failure until much later (e.g. when the state set by these method invocation won't be available after activation). Of course this is an unlikely scenario though it makes me wonder whether non-public final methods on a session bean with bean class local view (not very common construct) are worth it. > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Joe Bergmark (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Joe Bergmark commented on CDI-362: ---------------------------------- If I understand correctly they are not even considered business methods of the EJB and therefore don't need to be proxied because they shouldn't even be called. > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-274. --------------------------- Resolution: Done Added this language to the spec. > BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation > ------------------------------------------------------------------------------------------ > > Key: CDI-274 > URL: https://issues.jboss.org/browse/CDI-274 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: faq > Fix For: 1.1.FD > > > We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method. > Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs. > PROPOSAL: > We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-362: ----------------------------------- well, those methods cannot get proxied technically. Thus we still shall not allow it. And EJB should neither. > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-362: -------------------------- Fix Version/s: 1.1.FD > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Fix For: 1.1.FD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Pete Muir (JIRA)

Pete Muir created CDI-362: ----------------------------- Summary: No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting Key: CDI-362 URL: https://issues.jboss.org/browse/CDI-362 Project: CDI Specification Issues Issue Type: Bug Reporter: Pete Muir E.g. // allowed by EJB // disallowed by CDI @Stateful @RequestScoped public class MyBean { final void m() { }; } public class Other { @EJB MyBean field; // PASS @Inject MyBean field; // FAIL - unproxyable } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

Fwd: [jsr345-experts] Final methods in a bean class?

by Pete Muir

FYI https://issues.jboss.org/browse/CDI-362 Begin forwarded message: > From: Marina Vatkina <marina.vatkina(a)oracle.com> > Subject: Re: [jsr345-experts] Re: Final methods in a bean class? > Date: 29 March 2013 20:53:01 GMT > To: Pete Muir <pmuir(a)bleepbleep.org.uk> > Cc: jsr345-experts(a)ejb-spec.java.net, Jeremy Bauer <jrbauer(a)us.ibm.com> > Reply-To: marina.vatkina(a)oracle.com > > On 3/29/13 1:39 PM, Pete Muir wrote: >> Note this is only a problem for session beans with a no-interface view. > > Correct. This is what we are looking at. >> >> We could clean this up in the CDI spec probably, by adjusting the proxyability requirements to be identical to EJB for no-interface session views. >> >> Worth doing? > > Yes. Please. > > -marina > >> >> On 29 Mar 2013, at 19:57, Marina Vatkina <marina.vatkina(a)oracle.com> wrote: >> >>> On 3/29/13 12:45 PM, Pete Muir wrote: >>>> On 29 Mar 2013, at 18:42, Jeremy Bauer <jrbauer(a)us.ibm.com> wrote: >>>> >>>>> I may have overlooked something, but does CDI allow non-private non-public methods to be final? >>>> No. Not *if* a proxy is required. >>> If the EJB container created the proxy, it won't include the non-public methods. Even if the CDI spec allows more, a compliant EJB container won't intercept on those... >>> >>> -marina >>>>> With the new rules, couldn't we have this situation? >>>>> >>>>> @Stateless public class MyBean { >>>>> final void m() { }; >>>>> } >>>>> >>>>> public class Other { >>>>> @EJB MyBean field; // PASS >>>>> @Inject MyBean field; // FAIL - unproxyable >>>>> } >>>>> >>>>> >>>>> -Jeremy >>>>> >>>>> >>>>> >>>>> From: Marina Vatkina <marina.vatkina(a)oracle.com> >>>>> To: jsr345-experts(a)ejb-spec.java.net, >>>>> Cc: Pete Muir <pmuir(a)bleepbleep.org.uk>, Jeremy Bauer/Rochester/IBM@IBMUS >>>>> Date: 03/28/2013 02:06 PM >>>>> Subject: [jsr345-experts] Re: Final methods in a bean class? >>>>> >>>>> >>>>> >>>>> So we are just catching up with the CDI spec ;) >>>>> >>>>> Thanks Pete. >>>>> >>>>> -marina >>>>> >>>>> On 3/28/13 11:21 AM, Pete Muir wrote: >>>>>> Static methods were never considered as a block to proxability. >>>>>> >>>>>> On 28 Mar 2013, at 18:20, Marina Vatkina <marina.vatkina(a)oracle.com> wrote: >>>>>> >>>>>>> How about static methods? >>>>>>> >>>>>>> thanks, >>>>>>> -marina >>>>>>> >>>>>>> On 3/28/13 11:12 AM, Pete Muir wrote: >>>>>>>> We updated the requirements in CDI to specifically exclude private methods from proxability requirements. Note we moved this to it's own section - 3.15 >>>>>>>> >>>>>>>> Pete >>>>>>>> >>>>>>>> On 28 Mar 2013, at 17:16, Marina Vatkina <marina.vatkina(a)oracle.com> wrote: >>>>>>>> >>>>>>>>> Well, Pete is on this list (and I'm cc-ing him here explicitly), but I don't think private final (or static final) methods should be restricted... >>>>>>>>> >>>>>>>>> -marina >>>>>>>>> >>>>>>>>> On 3/28/13 9:30 AM, Jeremy Bauer wrote: >>>>>>>>>> Hi Marina, >>>>>>>>>> >>>>>>>>>> Won't allowing final methods will cause an inconsistency with the CDI spec? CDI 1.0 section 5.4.1 says: >>>>>>>>>> >>>>>>>>>> Certain legal bean types cannot be proxied by the container: >>>>>>>>>> [...] >>>>>>>>>> • classes which are declared final or have final methods, >>>>>>>>>> >>>>>>>>>> And I believe this is true in CDI 1.1, but I don't have that spec handy. >>>>>>>>>> >>>>>>>>>> -Jeremy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From: Marina Vatkina <marina.vatkina(a)oracle.com> >>>>>>>>>> To: jsr345-experts(a)ejb-spec.java.net, >>>>>>>>>> Date: 03/27/2013 06:21 PM >>>>>>>>>> Subject: [jsr345-experts] Re: Final methods in a bean class? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After a longer discussion with Mark offline and not to allow users to >>>>>>>>>> shoot themselves into a foot, the new proposal is to change both >>>>>>>>>> statements as follow: >>>>>>>>>> >>>>>>>>>> (a) "All non-static public methods of the bean class and of any >>>>>>>>>> superclasses except the java.lang.Object, are exposed as business methods." >>>>>>>>>> >>>>>>>>>> (b) "Business methods exposed through the no-interface view must not be >>>>>>>>>> declared final." >>>>>>>>>> >>>>>>>>>> Let me know if anybody disagrees. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> -marina >>>>>>>>>> >>>>>>>>>> On 3/27/13 11:36 AM, Marina Vatkina wrote: >>>>>>>>>>> Experts, >>>>>>>>>>> >>>>>>>>>>> The EJB spec currently requires that if a bean exposes a no-interface >>>>>>>>>>> view (see 4.9.8 Session Bean’s No-Interface View): >>>>>>>>>>> >>>>>>>>>>> (a) "All public methods of the bean class and of any superclasses >>>>>>>>>>> except the java.lang.Object, are exposed as business methods through >>>>>>>>>>> the no-interface view." >>>>>>>>>>> (b) "All methods of the bean class and any superclasses must not be >>>>>>>>>>> declared final." >>>>>>>>>>> >>>>>>>>>>> For all other views the rules for a *business method* is >>>>>>>>>>> "The method must not be declared as final or static." >>>>>>>>>>> >>>>>>>>>>> Does any of you see a problem with removing the rule (b) and changing >>>>>>>>>>> the rule (a) to: >>>>>>>>>>> >>>>>>>>>>> "All non-final non-static public methods of the bean class and of any >>>>>>>>>>> superclasses except the java.lang.Object, are exposed as business >>>>>>>>>>> methods through the no-interface view." >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> -marina >>>>>>>>>>> >>>>>>>>>>> >

11 years

1
0
0 / 0

[JBoss JIRA] (CDI-36) ObserverMethod.notify() does not forward qualifiers for Event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-36?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-36: ------------------------------ Please review https://github.com/jboss/cdi/pull/190 which updates Lincoln's pull to be more consistent language wise. > ObserverMethod.notify() does not forward qualifiers for Event > ------------------------------------------------------------- > > Key: CDI-36 > URL: https://issues.jboss.org/browse/CDI-36 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Reporter: Jordan Ganoff > Assignee: Pete Muir > Fix For: 1.1.FD > > > There's currently no way to get the qualifiers for a fired event. ObserverMethod.notify() only passes the event object itself. Without the qualifiers it is difficult to bridge the gap between CDI events and some other event infrastructure (e.g. JMS). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2013