Cool news. So I have been playing with the JUEL plugin (JUEL is pretty
nice, we can talk about that later.), and here are a few things I got
working so far:
1. Value stack operations (get/set)
2. I18n (there is a custom 'getText()' that works like it does now)
3. Parameter population
4. Most of Showcase
5. Method invocation in expressions
yeah, you read #3 right. My new parameter binder stuff is useless(3
days in trunk and already getting deleted whoa) and I will remove it
from xwork. I handled to implement the parameter binding with the JUEL
plugin, and it seems to be working nicely, population of null elements
and type conversion. On top of that I extended JUEL to support a "#"
operator, so an OGNL expression like
${#obj.x} or #{#obj.x}
does what you would expect it to do(no standard compliant but handy).
This enables us to run a rather large number of existing OGNL
expressions without changes. I gave it a try on showcase and it seems
to run most of it. I will be adding more test and cleanup the code and
commit it. I also "implemented" (more like "copied", merging code from
xwork and OGNL) a ReflectionProvider which does not need OGNL.
//all hail our new UEL overlord
musachy
On Sat, Jul 18, 2009 at 3:06 PM, Musachy Barroso <musa...@gmail.com> wrote:
> Due to this fix: http://jira.opensymphony.com/browse/OGNL-141
>
> Ognl 2.7.3 performance is a lot better than 2.6.11, on my rough test,
> the avg time spent in OgnlRuntime.invokeMethod(...) dropped from
> 630,726 ms (2.6.11) to 117,108 (2.7.3) ms, (100 threads, 2s ramp-up
> period, 100 iterations) . If we are not going to use the new bycode
> stuff, then the upgrade doesn't seem that risky. Should we upgrade, do
> some testing, and release 2.1.8 (delay release a bit), or leave that
> for 2.1.9? With the bytecode stuff out the way I am inclined to just
> upgrade to 2.7.3 at once, and upgrade freemarker also.
>
> musachy
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
