On 03/17/10 15:59, Jason Porter wrote:
> On Wed, Mar 17, 2010 at 16:39, Kin-man Chung<Kin-Man.Chung_at_sun.com> wrote:
>>
>> Since we already allow methods in EL expressions in EL 2.2, we should
>> extend this to include static methods. The most obvious syntax to use
>> is to include the package name, such as
>>
>> "#{com.acme.bar.method())"
>>
>> The downside is that we are overloading the meaning of the . operator
>> here, and might cause problems in parsing. There may be other ways.
>
> Would be it too much to assume that the class would already be a bean
> that we could resolve? If we had that limitation then we avoid the
> package problem. Although not having to have the class be resolvable
> via any other lookup would really increase the pool of allowable
> functions such as things from Apache commons-lang.
Well, the point of using a static method is not requiring an bean
instance. We should not have such restriction.
>
> We could control those classes with a file in the META-INF say
> META-INF/staticFunctions or some other name that would a newline
> delimited FQN of the class that contains static methods, then look
> through those for a matching method signature. Probably not a great
> idea, but it may stir other thoughts.
>
I don't like having another file for this. Its also won't work well
outside of web container. It'd be best if we can have the necessary
pieces in EL itself, if not in the expression, at least in the API.
>> I'd assume we'd deprecate FunctionMapper and not include it in
>> ELProcessor.
>>
>> -Kin-man
>