geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: apis @asf
Date Sun, 18 May 2014 14:58:49 GMT
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 <rmannibucau@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 <markt@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
>

Mime
View raw message