On 16/09/2013 14:43, Xavier Dury wrote: > I built tomcat from trunk (rev 1523639) and I'm having the same issue I had > with glassfish EL implementation when using overloaded methods: > > javax.el.ELException: Cannot convert ./ of type class java.lang.String to > class java.net.URI > at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:482) > at > org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48) > at javax.el.ELContext.convertToType(ELContext.java:473) > at > org.apache.el.lang.EvaluationContext.convertToType(EvaluationContext.java:155) > at javax.el.ELUtil.invokeConstructor(ELUtil.java:261) > at javax.el.StaticFieldELResolver.invoke(StaticFieldELResolver.java:203) > at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) > at org.apache.el.parser.AstFunction.getValue(AstFunction.java:138) > at > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188) > at javax.el.ELProcessor.getValue(ELProcessor.java:129) > at javax.el.ELProcessor.eval(ELProcessor.java:115) > at > org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43) > > So I guess it's normal behaviour, isn't it? > > I don't think EL spec does mandate implementations to make their best effort > to find a suitable method when invoking overloaded methods.
My intention with the Tomcat EL implementation is to replicate, as far as possible, the matching process that the Java compiler uses. If you open a bug and include a test case along the lines of this one[1], I'll take a look. Mark [1] http://svn.apache.org/viewvc/tomcat/trunk/test/javax/el/TestUtil.java?view=annotate --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
