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 Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-362: ------------------------------- So, if we want to tidy this up, we need to alter Section 6.3 to require the client proxy to only delegate business method invocations, not all method calls. We then need to adjust proxying requirements to only affect business methods for EJBs. Worth doing? Or not a problem in reality? > 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, 9 months

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 edited comment on CDI-362 at 4/4/13 5:41 AM: ------------------------------------------------------------- {quote}Actually the EJB spec is very strict "Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException"{quote} Assuming a protected method is final how do you detect that it was invoked? Where do you place the piece to throw EJBException? You obviously cannot have a proxy wrap the method call. was (Author: jharting): {quote}Actually the EJB spec is very strict "Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException"{quote} Assuming a protected method is final how do you detect that it was invoked? Where do you place the piece to throw EJBException? > 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, 9 months

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: ------------------------------------- {quote}Actually the EJB spec is very strict "Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException"{quote} Assuming a protected method is final how do you detect that it was invoked? Where do you place the piece to throw EJBException? > 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, 9 months

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 Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-362: ---------------------------------------- Yes, i think almost all containers implemented the link between CDI and EJB through "another proxy" so basically the EJB proxy will prevent more than what is allowed in CDI + final methods are forbidden in EJBs too (even public) > 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, 9 months

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 Marina Vatkina (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Marina Vatkina commented on CDI-362: ------------------------------------ Actually the EJB spec is very strict "Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException" > 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, 9 months

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 Marina Vatkina (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Marina Vatkina commented on CDI-362: ------------------------------------ A *compliant* EJB container should proxy only public methods of a bean with a no-interface view. If it does, only public bean methods invocations would go through the EJB container, i.e. handling of transaction/interceptor/security will be performed only for the public methods. Any other method invocation would go directly to the bean class. Probably all protected or package private methods on a no-interface bean should have been disallowed (it's too late now) because they produce a dangerous situation - they are available on the proxy, but shouldn't be called through 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, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-363) Revert changes to InjectionPoint that allow it to be injected in observer methods

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-363: ----------------------------------- Summary: Revert changes to InjectionPoint that allow it to be injected in observer methods Key: CDI-363 URL: https://issues.jboss.org/browse/CDI-363 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 1.1.PFD Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Blocker Fix For: 1.1.FD Now that EventMetadata made it to the spec this is now redundant. -- 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, 9 months

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: ------------------------------------- {quote}A client proxy implements/extends some or all of the bean types of the bean and delegates *all method calls* to the current instance (as defined in Section 6.3, “Normal scopes and pseudo-scopes”) of the bean.{quote} > 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, 9 months

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 commented on CDI-362: ------------------------------- Whilst the CDI client proxies may, in practice, proxy those methods, I can't find any evidence in the spec that they are *supposed* to do this (beyond the language we added in CDI 1.1, which we can still change). The language I found said that we only treat EJB business methods as CDI business method invocations (on which decoration, interception etc can happen), and that only EJB business methods can be things like producer methods. So, my initial reasoning is that CDI shouldn't proxy anything but EJB business methods (i.e. public methods) on no-interface session beans. If this is the case, then the validation should be the same as EJB, I think. > 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, 9 months

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 resolved CDI-36. -------------------------- Resolution: Done Merged > 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2013