Well, not sure it has to do with it, but since 7.0.53 I get a MethodNotFound in a project which used to work since years if the EL has a null parameter:
java.lang.NoSuchMethodException: de.jaxenter.eesummit.caroline.gui.beans.Menu$$OwbNormalScopeProxy0.activateMenuItem(null) java.lang.Class.getMethod(Class.java:1665) javax.el.BeanELResolver.invoke(BeanELResolver.java:394) javax.el.CompositeELResolver.invoke(CompositeELResolver.java:225) org.apache.el.parser.AstValue.getValue(AstValue.java:173) org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184) org.apache.webbeans.el22.WrappedValueExpression.getValue(WrappedValueExpression.java:70) Switching back only the tomcat-jasper-el.jar to 7.0.52 fixes the issue. The difference between those 2 versions is that in BeanELResolver of 7.0.53 I get a paramTyps[1] which contains a null value whereas in 7.0.52 and earlier the paramTypes itself is null. LieGrue, strub On Friday, 16 May 2014, 20:53, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > >Hi > >svn copy would be at least a nice solution to avoid kind of forks > >For sure would be great to aligned it both impl. I think geronimo is >the place since most of project are using these APIs (tomee, openejb, >openwebbeans, bval, jcs soon, openjpa, ...) > >about the bug the type parameter resolution is not done in resolver >where before invoke was passing correct types. Didnt check the spec >about it. > >Not sure the work needed to go this way, any idea how we can go further? > > > > >Romain Manni-Bucau >Twitter: @rmannibucau >Blog: http://rmannibucau.wordpress.com/ >LinkedIn: http://fr.linkedin.com/in/rmannibucau >Github: https://github.com/rmannibucau > > > >2014-05-16 16:32 GMT+02:00 Mark Thomas <ma...@apache.org>: >> On 16/05/2014 07:59, Romain Manni-Bucau wrote: >>> Hello guys, >>> >>> Hope I didnt miss a thread dealing with it, if so please just redirect me. >>> >>> Tomcat made the choice to do its own API jars. That's not a big deal >>> by itself but wonder why not putting them with all "EE" api jars of >>> Apache, ie in geronimo specs subproject: >>> http://svn.apache.org/repos/asf/geronimo/specs/trunk/ >> >> I suspect it stems from the fact the Tomcat was originally the reference >> implementation for a number of those. >> >>> It concerns mainly: >>> * el >>> * websocket >>> * jsp >>> * servlet >>> >>> Just to give you a bit more background, this question doesn't come >>> from nowhere. In TomEE we use geronimo API for almost everything >>> excepted some tomcat provided apis (servlet, jsp) until today. But >>> since recent Tomcat 7 got - thanks to Tomcat 8 - a refactoring of EL >>> part, geronimo-el and tomcat-el were no more compatible. In other >>> words TomEE was broken cause AstValue was refactored and method >>> matching more dedicated to BeanELResolver in tomcat but not in >>> geronimo. >> >> Doesn't that simply mean that the refactoring in Tomcat has exposed a >> bug in the Geronimo EL API? >> >>> Wonder if we should/can try to get something consistent accross ASF. >> >> Assuming that Geronimo is using the Tomcat implementations I wonder why >> the project felt the need to produce their own API JARs. Or are they >> just (old?) copies taken from Tomcat originally? >> >>> wdyt? >> >> From experience with re-using components from Commons, Tomcat would >> almost certainly want to keep a local copy - even if that was an svn >> copy of some common version - else releases can start to experience >> noticeable delays waiting on a release of a dependency. >> >> Mark >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
