On 20/09/2013 02:38, Esmond Pitt wrote:
>
> Mark
>
> Can I direct your attention to java.beans.Statement and
> java.beans.Expression. They already do all the matching you're talking
> about.
I took a look (I even committed it [1]) and they do work well apart from
the handling of varargs. For example
foo.bar("a", "b", "c", "d")
is not matched to
Foo.bar(String, String...)
Unfortunately, we need the vararg handling and I couldn't see an easy
way to get this to work so I reverted the change and went back to the
manual matching.
I'd be very happy to see this working. If someone wants to look at the
patch below and see if they can tweak it so all the unit tests pass then
I'd be happy to take another look.
Mark
[1] http://svn.apache.org/r1523988
>
> EJP
>
> Forward to the list as per Marks' request.
>
> -----Original Message-----
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, 17 September 2013 12:02 AM
> To: Tomcat Users List
> Subject: Re: Using EL expressions in an ObjectFactory
>
> 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:15
> 5)
>> 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.elImplementationShould
>> Work(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=a
> nnotate
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
