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 Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-362: ----------------------------------- oki in that case it's fine. I was under the impression that you also like to change the rules for CDI beans. Still would need to tackle the @Stateful @SomeCdiScope case. Should those get handled via EJB proxies or via CDI proxies? > 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, 8 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: ------------------------------------- I filed http://java.net/jira/browse/EJB_SPEC-104. I think we should not proceed further with this issue until the EJB one is resolved. > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-364) EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-364?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-364: ------------------------------------- To be more precise it should be: The type representing runtime class of the event object with type variables resolved. > EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead > -------------------------------------------------------------------------------------------------- > > Key: CDI-364 > URL: https://issues.jboss.org/browse/CDI-364 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > > Also it's not entirely clear what "the resolved event Type" means... no such term was used in the Events section before. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-364) EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-364?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-364: ------------------------------------- Yes, it should probably say explicitly that it is an event type with resolved type variables (or introduce a term for this and use it throughout the spec). > EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead > -------------------------------------------------------------------------------------------------- > > Key: CDI-364 > URL: https://issues.jboss.org/browse/CDI-364 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > > Also it's not entirely clear what "the resolved event Type" means... no such term was used in the Events section before. -- 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, 8 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: ------------------------------- Right, this would only be an additional change for no-interface session beans, which doesn't work anyway if the EJB container is struct. > 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, 8 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: ---------------------------------------- @Mark: i didn't get this issue this way. I thought the limitations we are talking about was only for ejb > 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, 8 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 Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-362: ----------------------------------- -1 a.) this is backward incompatible to CDI-1.0 b.) why should we restrict ourselfs for pure CDI beans just because EJBs made this error long time ago (and cannot change this because of backward compat reasons in EJB) There is really no technical reason why protected and package scoped methods should not be proxied. > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-364) EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-364?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-364: ----------------------------- Summary: EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead (was: EventMetadata - API declares getType() method but the spec test declares getResolvedType() instead) > EventMetadata - API declares getType() method but the spec text declares getResolvedType() instead > -------------------------------------------------------------------------------------------------- > > Key: CDI-364 > URL: https://issues.jboss.org/browse/CDI-364 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > > Also it's not entirely clear what "the resolved event Type" means... no such term was used in the Events section before. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-364) EventMetadata - API declares getType() method but the spec test declares getResolvedType() instead

by Martin Kouba (JIRA)

Martin Kouba created CDI-364: -------------------------------- Summary: EventMetadata - API declares getType() method but the spec test declares getResolvedType() instead Key: CDI-364 URL: https://issues.jboss.org/browse/CDI-364 Project: CDI Specification Issues Issue Type: Bug Reporter: Martin Kouba Assignee: Pete Muir Fix For: 1.1.FD Also it's not entirely clear what "the resolved event Type" means... no such term was used in the Events section before. -- 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, 8 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: ---------------------------------------- basically EJB proxies created for no-interface view ejb doesn't always propagate the not public methods so it is even not available. I agree the spec is ambiguous but i don't think that's an issue in practise (= you can get the case but you quickly find something is wrong) > 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2013