You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2009/07/19 01:06:31 UTC
ognl 2.7.3 performance
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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Lukasz Lenart <lu...@googlemail.com>.
2009/7/29 Rainer Hermanns <he...@aixcept.de>:
> thanks! I'll wait for the TextProvider problem to be fixed and then fire
> up the release process. I start a new gig next week, so this will most
> likely happen until/over the weekend.
I solved these problems and was able to confirm that with test, but
right now I want to prepare some test application with custom
TextProvider and see how is it work.
Regards
--
Lukasz
http://www.lenart.org.pl/
http://dailylog.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Rainer Hermanns <he...@aixcept.de>.
Musachy,
thanks! I'll wait for the TextProvider problem to be fixed and then fire
up the release process. I start a new gig next week, so this will most
likely happen until/over the weekend.
Rainer
> showcase seems fine. Rainer, whenever you can, get us an xwork release :)
>
> musachy
>
> On Thu, Jul 23, 2009 at 10:57 AM, Musachy Barroso<mu...@gmail.com>
> wrote:
>> I am done with the changes in xwork. Whoever can give a hand testing
>> what is in trunk, this is a good time to jump in :). If everything is
>> ok, we can release xwork and then do the 2.1.8 release.
>>
>> musachy
>>
>> On Sat, Jul 18, 2009 at 4:06 PM, Musachy Barroso<mu...@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
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Rainer Hermanns
aixcept
Willibrordstraße 82
52134 Herzogenrath - Germany
w: http://aixcept.de/
t: +49 - 2406 - 979 22 11
f: +49 - 2406 - 979 22 13
m: +49 - 170 - 343 29 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
showcase seems fine. Rainer, whenever you can, get us an xwork release :)
musachy
On Thu, Jul 23, 2009 at 10:57 AM, Musachy Barroso<mu...@gmail.com> wrote:
> I am done with the changes in xwork. Whoever can give a hand testing
> what is in trunk, this is a good time to jump in :). If everything is
> ok, we can release xwork and then do the 2.1.8 release.
>
> musachy
>
> On Sat, Jul 18, 2009 at 4:06 PM, Musachy Barroso<mu...@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
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
I am done with the changes in xwork. Whoever can give a hand testing
what is in trunk, this is a good time to jump in :). If everything is
ok, we can release xwork and then do the 2.1.8 release.
musachy
On Sat, Jul 18, 2009 at 4:06 PM, Musachy Barroso<mu...@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
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
What Chris said. Plus, adopting a standard is a good idea, UEL could
even be the default EL for Struts 3, and OGNL a plugin by that time :)
musachy
On Fri, Nov 6, 2009 at 6:25 PM, Chris Pratt <th...@gmail.com> wrote:
> It's slow and confusing. The slow part is pretty self explanatory, but the
> confusing part might take more explanation.
>
> This is what I have to try to get across to my junior developers that are
> trying to grasp not only Struts, but Spring, Tiles and our own code as well.
>
> In the struts.xml file you can use ${} to run an OGNL expression and access
> things from the Action (actually the value stack, but we're trying to keep
> it simple here)
>
> If you see ${} in a .jsp file, that's no longer OGNL, it's JSTL EL and that
> can be used anywhere in JSP, except within the Struts tags. For them, and
> them only, you have to use %{} to execute the same OGNL you saw in the
> struts.xml (I know you don't always have to, but it's easier then explaining
> when you do and when you don't).
>
> And then it gets more confusing when you try to describe how to format
> values like dates and currencies, and on and on...
>
> For me, I've never needed anything that good old JSTL EL didn't provide. In
> fact, I LIKE the fact that JSTL EL prevents me from accessing anything but
> bean properties. I think it opens up a whole world of security hurt when
> you have an interpreted language that potentially allows accessing any Java
> method remotely.
>
> That's just my 2 cents, but I'm very glad to see Musachy take up this
> mantle!
> (*Chris*)
>
> On Fri, Nov 6, 2009 at 6:14 PM, Alex Siman <al...@gmail.com>wrote:
>
>>
>> What was the reason(s) to get rid of OGNL? Just interesting.
>>
>> Musachy Barroso wrote:
>> >
>> > 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 <mu...@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-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/ognl-2.7.3-performance-tp24552642p26234947.html
>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
in 2.1.6 I think.
On Fri, Nov 6, 2009 at 11:47 PM, Chris Pratt <th...@gmail.com> wrote:
> Good to know, thanks. When was that changed? I use 2.1.6 in my personal
> project, but we're still stuck on 2.0.14 at work.
> (*Chris*)
>
> On Fri, Nov 6, 2009 at 11:33 PM, Dale Newfield <da...@newfield.org> wrote:
>
>> Chris Pratt wrote:
>>
>>> In the struts.xml file you can use ${} to run an OGNL expression and
>>> access
>>> things from the Action (actually the value stack, but we're trying to keep
>>> it simple here)
>>>
>>
>> JSYK, %{} now works as expected in struts.xml.
>>
>> -Dale
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
Good to know, thanks. When was that changed? I use 2.1.6 in my personal
project, but we're still stuck on 2.0.14 at work.
(*Chris*)
On Fri, Nov 6, 2009 at 11:33 PM, Dale Newfield <da...@newfield.org> wrote:
> Chris Pratt wrote:
>
>> In the struts.xml file you can use ${} to run an OGNL expression and
>> access
>> things from the Action (actually the value stack, but we're trying to keep
>> it simple here)
>>
>
> JSYK, %{} now works as expected in struts.xml.
>
> -Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Dale Newfield <da...@newfield.org>.
Chris Pratt wrote:
> In the struts.xml file you can use ${} to run an OGNL expression and access
> things from the Action (actually the value stack, but we're trying to keep
> it simple here)
JSYK, %{} now works as expected in struts.xml.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
It's slow and confusing. The slow part is pretty self explanatory, but the
confusing part might take more explanation.
This is what I have to try to get across to my junior developers that are
trying to grasp not only Struts, but Spring, Tiles and our own code as well.
In the struts.xml file you can use ${} to run an OGNL expression and access
things from the Action (actually the value stack, but we're trying to keep
it simple here)
If you see ${} in a .jsp file, that's no longer OGNL, it's JSTL EL and that
can be used anywhere in JSP, except within the Struts tags. For them, and
them only, you have to use %{} to execute the same OGNL you saw in the
struts.xml (I know you don't always have to, but it's easier then explaining
when you do and when you don't).
And then it gets more confusing when you try to describe how to format
values like dates and currencies, and on and on...
For me, I've never needed anything that good old JSTL EL didn't provide. In
fact, I LIKE the fact that JSTL EL prevents me from accessing anything but
bean properties. I think it opens up a whole world of security hurt when
you have an interpreted language that potentially allows accessing any Java
method remotely.
That's just my 2 cents, but I'm very glad to see Musachy take up this
mantle!
(*Chris*)
On Fri, Nov 6, 2009 at 6:14 PM, Alex Siman <al...@gmail.com>wrote:
>
> What was the reason(s) to get rid of OGNL? Just interesting.
>
> Musachy Barroso wrote:
> >
> > 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 <mu...@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-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/ognl-2.7.3-performance-tp24552642p26234947.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Alex Siman <al...@gmail.com>.
What was the reason(s) to get rid of OGNL? Just interesting.
Musachy Barroso wrote:
>
> 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 <mu...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/ognl-2.7.3-performance-tp24552642p26234947.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: WW-3291. Checkin and moving forward...
Posted by Musachy Barroso <mu...@gmail.com>.
I am sorry, I was to excited about the JUEL plugin and totally forgot
about it. If you have additional changes, create a new patch and I
will merge that one.
musachy
On Fri, Nov 6, 2009 at 9:40 AM, Christian Stone <xt...@stonescape.net> wrote:
> I was wondering if you had a chance to commit the patch I submitted with
> this bug [WW-3291]. I did more work in the project with another issue
> (using freemarker and velocity templates interchangeably as decorators with
> the same *full* value stack) and wish to push that. Since both bugs take
> place in the same codebase, I am wondering if I should just send you a
> single patch for both, or wait until the one is closed before creating a
> patch for the other issue.
>
> On a side note, I moved the changes I made into several production clients.
> I have websites with more than a dozen decorators and hundreds of view
> files. I am _finally_ able to start the migration to Freemarker from
> Velocity that I wasn't able to do before. I converted 4 of the files to
> Freemarker without having the overhead of needing to convert all of them in
> one sitting. It is glorious. Also, I am able to access all the statics and
> whatnot that I couldn't before, so using static keys is a huge blessing for
> readability. Also, the enhanced error reporting has already helped me
> several times diagnose issues on the server.
>
> Anyways, congrats on the work you just accomplished. Two of the biggest
> complaints on Struts 2 are speed and error reporting. Any steps to mitigate
> either of these issues is a huge win!
>
> -- Christian Stone
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: WW-3291. Checkin and moving forward...
Posted by Christian Stone <xt...@stonescape.net>.
I was wondering if you had a chance to commit the patch I submitted
with this bug [WW-3291]. I did more work in the project with another
issue (using freemarker and velocity templates interchangeably as
decorators with the same *full* value stack) and wish to push that.
Since both bugs take place in the same codebase, I am wondering if I
should just send you a single patch for both, or wait until the one is
closed before creating a patch for the other issue.
On a side note, I moved the changes I made into several production
clients. I have websites with more than a dozen decorators and
hundreds of view files. I am _finally_ able to start the migration to
Freemarker from Velocity that I wasn't able to do before. I converted
4 of the files to Freemarker without having the overhead of needing to
convert all of them in one sitting. It is glorious. Also, I am able
to access all the statics and whatnot that I couldn't before, so using
static keys is a huge blessing for readability. Also, the enhanced
error reporting has already helped me several times diagnose issues on
the server.
Anyways, congrats on the work you just accomplished. Two of the
biggest complaints on Struts 2 are speed and error reporting. Any
steps to mitigate either of these issues is a huge win!
-- Christian Stone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
yes definitely. We could create an interface for it, and leave the
simple binder as an implementation. If there is interest in something
like that we can bring it back. I will put the new reflection provider
in xwork because it is not tied to JUEL, and can be used by other
implementations, like the simple parameters binder itself.
musachy
On Fri, Nov 6, 2009 at 5:13 AM, Rene Gielen <gi...@it-neering.net> wrote:
> That's awesome, man!
>
> One question: Wouldn't the parameters binder be helpful to enhance
> pluggability in general, especially regarding other ELs? Such as to have
> a CustomParametersBinder Interface, for which a user can optionally
> configure it's desired binder? Let's say for MVEL, or maybe supporting
> different property concepts in other platform languages, such as Scala.
> Your SimpleBinder stuff looked too good to be simply dropped, IMO :)
>
> - René
>
> Musachy Barroso schrieb:
>> 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 <mu...@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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)177-3194448
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Rene Gielen <gi...@it-neering.net>.
That's awesome, man!
One question: Wouldn't the parameters binder be helpful to enhance
pluggability in general, especially regarding other ELs? Such as to have
a CustomParametersBinder Interface, for which a user can optionally
configure it's desired binder? Let's say for MVEL, or maybe supporting
different property concepts in other platform languages, such as Scala.
Your SimpleBinder stuff looked too good to be simply dropped, IMO :)
- René
Musachy Barroso schrieb:
> 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 <mu...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
That's awesome Musachy, you da man!
(*Chris*)
On Thu, Nov 5, 2009 at 4:41 PM, Musachy Barroso <mu...@gmail.com> wrote:
> 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 <mu...@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
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 <mu...@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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
I need some maven black magic support, running mvn dependency:tree,
from apps/blank outputs:
[INFO] org.apache.struts:struts2-blank:war:2.1.8-SNAPSHOT
[INFO] +- javax.servlet:servlet-api:jar:2.4:provided
[INFO] +- javax.servlet:jsp-api:jar:2.0:provided
[INFO] +- org.apache.struts:struts2-junit-plugin:jar:2.1.8-SNAPSHOT:test
[INFO] | \- org.springframework:spring-core:jar:2.5.6:test
[INFO] +- org.apache.struts:struts2-core:jar:2.1.8-SNAPSHOT:compile
[INFO] | +- com.opensymphony:xwork-core:jar:2.1.5-SNAPSHOT:compile
[INFO] | | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | | +- opensymphony:ognl:jar:2.6.11:compile
[INFO] | | +- asm:asm:jar:3.1:compile
[INFO] | | \- asm:asm-commons:jar:3.1:compile
[INFO] | | \- asm:asm-tree:jar:3.1:compile
[INFO] | +- org.freemarker:freemarker:jar:2.3.15:compile
[INFO] | +- ognl:ognl:jar:2.7.3:compile
[INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
[INFO] | +- commons-io:commons-io:jar:1.3.2:compile
[INFO] | \- com.sun:tools:jar:1.5.0:system
[INFO] \- org.springframework:spring-test:jar:2.5.6:test (scope not
updated to compile)
[INFO] +- commons-logging:commons-logging:jar:1.1.1:test
[INFO] \- junit:junit:jar:3.8.1:test
but the asm dependency is marked as "optional" in xwork, so it
shouldn't be resolved as a transitive dependency, anyone knows what's
up here?
musachy
On Mon, Jul 20, 2009 at 9:50 AM, Musachy Barroso<mu...@gmail.com> wrote:
> that's good to hear, I haven't tried it yet without that dep.
>
> musachy
>
> On Mon, Jul 20, 2009 at 9:46 AM, Chris Pratt<th...@gmail.com> wrote:
>> That may be only for the compilation. I'm using it without those libraries
>> and haven't had any problems.
>> (*Chris*)
>>
>> On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>
>>> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
>>>
>>> musachy
>>>
>>> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
>>> wrote:
>>> > +1, both make sense to wait for, cause the performance improvement
>>> > will satisfy lots of our users...
>>> > That's the reason, why xwork is not yet released :)
>>> >
>>> > cheers,
>>> > Rainer
>>> >
>>> >> Sounds good. It gives rainer some more time to get xwork released.
>>> >>
>>> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>>> >>> Musachy Barroso <mu...@gmail.com> wrote:
>>> >>>> With the bytecode stuff out the way I am inclined to just
>>> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>>> >>>
>>> >>> +1
>>> >>>
>>> >>> -Dale
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> >>> For additional commands, e-mail: dev-help@struts.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Wes Wannemacher
>>> >> Author - Struts 2 In Practice
>>> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
>>> >> http://www.manning.com/wannemacher
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> >> For additional commands, e-mail: dev-help@struts.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Rainer Hermanns
>>> > aixcept
>>> > Willibrordstraße 82
>>> > 52134 Herzogenrath - Germany
>>> > w: http://aixcept.de/
>>> > t: +49 - 2406 - 979 22 11
>>> > f: +49 - 2406 - 979 22 13
>>> > m: +49 - 170 - 343 29 12
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> > For additional commands, e-mail: dev-help@struts.apache.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
that's good to hear, I haven't tried it yet without that dep.
musachy
On Mon, Jul 20, 2009 at 9:46 AM, Chris Pratt<th...@gmail.com> wrote:
> That may be only for the compilation. I'm using it without those libraries
> and haven't had any problems.
> (*Chris*)
>
> On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
>>
>> musachy
>>
>> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
>> wrote:
>> > +1, both make sense to wait for, cause the performance improvement
>> > will satisfy lots of our users...
>> > That's the reason, why xwork is not yet released :)
>> >
>> > cheers,
>> > Rainer
>> >
>> >> Sounds good. It gives rainer some more time to get xwork released.
>> >>
>> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >>>> With the bytecode stuff out the way I am inclined to just
>> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >>>
>> >>> +1
>> >>>
>> >>> -Dale
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Wes Wannemacher
>> >> Author - Struts 2 In Practice
>> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
>> >> http://www.manning.com/wannemacher
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Rainer Hermanns
>> > aixcept
>> > Willibrordstraße 82
>> > 52134 Herzogenrath - Germany
>> > w: http://aixcept.de/
>> > t: +49 - 2406 - 979 22 11
>> > f: +49 - 2406 - 979 22 13
>> > m: +49 - 170 - 343 29 12
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
ah..I didnt make it up after all:
http://blogs.sun.com/kchung/entry/jsr_245_mr_part_i
On Tue, Nov 3, 2009 at 4:04 PM, Musachy Barroso <mu...@gmail.com> wrote:
> yeah I have to look into that, it seems like the last jar in their
> maven repo doesn't have the latest api. The JUEL demo now works with
> the simple parameters binder, so a dumb form like:
>
> <s:form action="SurveySave">
> <s:textfield label="First Name"
> name="#{surveyBean.firstName}"></s:textfield>
> <s:textfield label="Last Name"
> name="#{surveyBean.lastName}"></s:textfield>
> <s:textfield label="Age" name="#{surveyBean.age}"></s:textfield>
> <s:textfield label="Birthday"
> name="#{surveyBean.birthdate}"></s:textfield>
> <s:submit value="Submit"/>
> </s:form>
>
> works, so basic parameters with type conversions is partially working.
> Long way to go but we have to start somewhere :). beta testers always
> welcome, you would need to build xwork and s2 from trunk and set
> struts.enableSimpleParametersBinder=true. There is a good chance that
> I broke something else, so let me know.
>
> musachy
>
> On Tue, Nov 3, 2009 at 11:52 AM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>> Well yes, that's by default, but with the new EL api you can plugin a
>>> new EL resolver like:
>>>
>>> JspApplicationContext jspApplicationContext =
>>> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
>>> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>>
>> Maybe I did not explain myself.
>> In a JSP page, an expression of the type:
>> ${something}
>> is treated as an expression. If you put such a string in a non-rtexpr
>> enabled attribute it will give you an error.
>>
>>> BTW the JUEL plugin...
>>
>> Leave JUEL and try Tomcat's EL like I did in tiles:
>> https://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-el
>> (notice that currently SVN seems down).
>> You can even load the default container EL implementation.
>> Take a look in particular at the configuration, because the EL API is
>> got from java.net repository, and the implementation from Tomcat.
>>
>> HTH
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
yeah I have to look into that, it seems like the last jar in their
maven repo doesn't have the latest api. The JUEL demo now works with
the simple parameters binder, so a dumb form like:
<s:form action="SurveySave">
<s:textfield label="First Name"
name="#{surveyBean.firstName}"></s:textfield>
<s:textfield label="Last Name"
name="#{surveyBean.lastName}"></s:textfield>
<s:textfield label="Age" name="#{surveyBean.age}"></s:textfield>
<s:textfield label="Birthday"
name="#{surveyBean.birthdate}"></s:textfield>
<s:submit value="Submit"/>
</s:form>
works, so basic parameters with type conversions is partially working.
Long way to go but we have to start somewhere :). beta testers always
welcome, you would need to build xwork and s2 from trunk and set
struts.enableSimpleParametersBinder=true. There is a good chance that
I broke something else, so let me know.
musachy
On Tue, Nov 3, 2009 at 11:52 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>> Well yes, that's by default, but with the new EL api you can plugin a
>> new EL resolver like:
>>
>> JspApplicationContext jspApplicationContext =
>> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
>> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>
> Maybe I did not explain myself.
> In a JSP page, an expression of the type:
> ${something}
> is treated as an expression. If you put such a string in a non-rtexpr
> enabled attribute it will give you an error.
>
>> BTW the JUEL plugin...
>
> Leave JUEL and try Tomcat's EL like I did in tiles:
> https://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-el
> (notice that currently SVN seems down).
> You can even load the default container EL implementation.
> Take a look in particular at the configuration, because the EL API is
> got from java.net repository, and the implementation from Tomcat.
>
> HTH
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Antonio Petrelli <an...@gmail.com>.
2009/11/3 Musachy Barroso <mu...@gmail.com>:
> Well yes, that's by default, but with the new EL api you can plugin a
> new EL resolver like:
>
> JspApplicationContext jspApplicationContext =
> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
> jspApplicationContext.addELResolver(new CompoundRootELResolver());
Maybe I did not explain myself.
In a JSP page, an expression of the type:
${something}
is treated as an expression. If you put such a string in a non-rtexpr
enabled attribute it will give you an error.
> BTW the JUEL plugin...
Leave JUEL and try Tomcat's EL like I did in tiles:
https://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-el
(notice that currently SVN seems down).
You can even load the default container EL implementation.
Take a look in particular at the configuration, because the EL API is
got from java.net repository, and the implementation from Tomcat.
HTH
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
The parameters binder branch is now merged into xwork trunk (manual
merge thanks to svn being a PITA)(for those unaware, this contains
some experimental code to set parameters in the actions without using
OGNL directly, it is faster, and more secure) . Now we can start
playing with other ELs seriously.
musachy
On Tue, Nov 3, 2009 at 10:20 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
> It's been a while, but that is really more of an current action stack (I
> call it the ActionInvocation stack). I recall that I was able to get most of
> the functionality I needed into JCatapult while still using the FTL/JSP
> expression languages.
>
> -bp
>
>
> On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote:
>
>> That would be ok except for one thing: the value stack. To support the
>> value stack in those view technologies is the problem. I have tried so
>> many things, and failed in all of them that it is lame. I will finally
>> merge my parameters-binder branch in xwork into trunk, and see if I
>> can get some folks to look at it. With the parameters problem solved,
>> the rest is not *that* hard.
>>
>> On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli <br...@pontarelli.com>
>> wrote:
>>>
>>> I still think that the simplest approach is still to do nothing except
>>> for
>>> EL and let the view technology do it all (JSP, FTL, VM, etc.). The only
>>> time
>>> you need anything remotely similar to EL is for getting and setting
>>> values
>>> out of beans. This is generally not EL handling, but basic JavaBean
>>> handling. This topic has come up so many times and I still feel it is a
>>> major barrier to entry for Struts.
>>>
>>> -bp
>>>
>>>
>>> On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
>>>
>>>> Well yes, that's by default, but with the new EL api you can plugin a
>>>> new EL resolver like:
>>>>
>>>> JspApplicationContext jspApplicationContext =
>>>> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
>>>> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>>>>
>>>> and the container will delegate to that resolver. BTW the JUEL plugin
>>>> is in better shape than I thought, Tom are you out there?
>>>>
>>>> musachy
>>>>
>>>> On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
>>>> <an...@gmail.com> wrote:
>>>>>
>>>>> 2009/11/3 Antonio Petrelli <an...@gmail.com>:
>>>>>>
>>>>>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>>>>>>
>>>>>>> We also have FreeMarker , Velocity and we have a lot of expression
>>>>>>> evaluations from Struts code itself.
>>>>>>
>>>>>> And in this case you're right, EL at Struts-side is obligatory.
>>>>>> But exactly, is a bad idea to use the capability of the container to
>>>>>> resolve EL expressions into values?
>>>>>> This is just an idea.
>>>>>
>>>>> Another thing, sorry for the noise :-D
>>>>>
>>>>> If EL Expressions are interpreted Struts-side, this means that in JSP
>>>>> tags the attributes that represent expressions should not be "rtexpr"
>>>>> activated.
>>>>> This means that they might not have an expression, so you cannot write:
>>>>> <struts:tag expression="${myexpr}" />
>>>>> because it is not interpreted as a string, but as an expression
>>>>> illegally placed.
>>>>> So you should do funny things, like string composition, to let it work.
>>>>>
>>>>> Antonio
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Brian Pontarelli <br...@pontarelli.com>.
It's been a while, but that is really more of an current action stack
(I call it the ActionInvocation stack). I recall that I was able to
get most of the functionality I needed into JCatapult while still
using the FTL/JSP expression languages.
-bp
On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote:
> That would be ok except for one thing: the value stack. To support the
> value stack in those view technologies is the problem. I have tried so
> many things, and failed in all of them that it is lame. I will finally
> merge my parameters-binder branch in xwork into trunk, and see if I
> can get some folks to look at it. With the parameters problem solved,
> the rest is not *that* hard.
>
> On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli <brian@pontarelli.com
> > wrote:
>> I still think that the simplest approach is still to do nothing
>> except for
>> EL and let the view technology do it all (JSP, FTL, VM, etc.). The
>> only time
>> you need anything remotely similar to EL is for getting and setting
>> values
>> out of beans. This is generally not EL handling, but basic JavaBean
>> handling. This topic has come up so many times and I still feel it
>> is a
>> major barrier to entry for Struts.
>>
>> -bp
>>
>>
>> On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
>>
>>> Well yes, that's by default, but with the new EL api you can
>>> plugin a
>>> new EL resolver like:
>>>
>>> JspApplicationContext jspApplicationContext =
>>> JspFactory.getDefaultFactory().getJspApplicationContext
>>> (servletContext);
>>> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>>>
>>> and the container will delegate to that resolver. BTW the JUEL
>>> plugin
>>> is in better shape than I thought, Tom are you out there?
>>>
>>> musachy
>>>
>>> On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
>>> <an...@gmail.com> wrote:
>>>>
>>>> 2009/11/3 Antonio Petrelli <an...@gmail.com>:
>>>>>
>>>>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>>>>>
>>>>>> We also have FreeMarker , Velocity and we have a lot of
>>>>>> expression
>>>>>> evaluations from Struts code itself.
>>>>>
>>>>> And in this case you're right, EL at Struts-side is obligatory.
>>>>> But exactly, is a bad idea to use the capability of the
>>>>> container to
>>>>> resolve EL expressions into values?
>>>>> This is just an idea.
>>>>
>>>> Another thing, sorry for the noise :-D
>>>>
>>>> If EL Expressions are interpreted Struts-side, this means that in
>>>> JSP
>>>> tags the attributes that represent expressions should not be
>>>> "rtexpr"
>>>> activated.
>>>> This means that they might not have an expression, so you cannot
>>>> write:
>>>> <struts:tag expression="${myexpr}" />
>>>> because it is not interpreted as a string, but as an expression
>>>> illegally placed.
>>>> So you should do funny things, like string composition, to let it
>>>> work.
>>>>
>>>> Antonio
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
That would be ok except for one thing: the value stack. To support the
value stack in those view technologies is the problem. I have tried so
many things, and failed in all of them that it is lame. I will finally
merge my parameters-binder branch in xwork into trunk, and see if I
can get some folks to look at it. With the parameters problem solved,
the rest is not *that* hard.
On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
> I still think that the simplest approach is still to do nothing except for
> EL and let the view technology do it all (JSP, FTL, VM, etc.). The only time
> you need anything remotely similar to EL is for getting and setting values
> out of beans. This is generally not EL handling, but basic JavaBean
> handling. This topic has come up so many times and I still feel it is a
> major barrier to entry for Struts.
>
> -bp
>
>
> On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
>
>> Well yes, that's by default, but with the new EL api you can plugin a
>> new EL resolver like:
>>
>> JspApplicationContext jspApplicationContext =
>> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
>> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>>
>> and the container will delegate to that resolver. BTW the JUEL plugin
>> is in better shape than I thought, Tom are you out there?
>>
>> musachy
>>
>> On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
>> <an...@gmail.com> wrote:
>>>
>>> 2009/11/3 Antonio Petrelli <an...@gmail.com>:
>>>>
>>>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>>>>
>>>>> We also have FreeMarker , Velocity and we have a lot of expression
>>>>> evaluations from Struts code itself.
>>>>
>>>> And in this case you're right, EL at Struts-side is obligatory.
>>>> But exactly, is a bad idea to use the capability of the container to
>>>> resolve EL expressions into values?
>>>> This is just an idea.
>>>
>>> Another thing, sorry for the noise :-D
>>>
>>> If EL Expressions are interpreted Struts-side, this means that in JSP
>>> tags the attributes that represent expressions should not be "rtexpr"
>>> activated.
>>> This means that they might not have an expression, so you cannot write:
>>> <struts:tag expression="${myexpr}" />
>>> because it is not interpreted as a string, but as an expression
>>> illegally placed.
>>> So you should do funny things, like string composition, to let it work.
>>>
>>> Antonio
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Brian Pontarelli <br...@pontarelli.com>.
I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic JavaBean handling. This topic has come up so many times and I
still feel it is a major barrier to entry for Struts.
-bp
On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
> Well yes, that's by default, but with the new EL api you can plugin a
> new EL resolver like:
>
> JspApplicationContext jspApplicationContext =
> JspFactory.getDefaultFactory().getJspApplicationContext
> (servletContext);
> jspApplicationContext.addELResolver(new CompoundRootELResolver());
>
> and the container will delegate to that resolver. BTW the JUEL plugin
> is in better shape than I thought, Tom are you out there?
>
> musachy
>
> On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> 2009/11/3 Antonio Petrelli <an...@gmail.com>:
>>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>>> We also have FreeMarker , Velocity and we have a lot of expression
>>>> evaluations from Struts code itself.
>>>
>>> And in this case you're right, EL at Struts-side is obligatory.
>>> But exactly, is a bad idea to use the capability of the container to
>>> resolve EL expressions into values?
>>> This is just an idea.
>>
>> Another thing, sorry for the noise :-D
>>
>> If EL Expressions are interpreted Struts-side, this means that in JSP
>> tags the attributes that represent expressions should not be "rtexpr"
>> activated.
>> This means that they might not have an expression, so you cannot
>> write:
>> <struts:tag expression="${myexpr}" />
>> because it is not interpreted as a string, but as an expression
>> illegally placed.
>> So you should do funny things, like string composition, to let it
>> work.
>>
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
Well yes, that's by default, but with the new EL api you can plugin a
new EL resolver like:
JspApplicationContext jspApplicationContext =
JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
jspApplicationContext.addELResolver(new CompoundRootELResolver());
and the container will delegate to that resolver. BTW the JUEL plugin
is in better shape than I thought, Tom are you out there?
musachy
On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2009/11/3 Antonio Petrelli <an...@gmail.com>:
>> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>>> We also have FreeMarker , Velocity and we have a lot of expression
>>> evaluations from Struts code itself.
>>
>> And in this case you're right, EL at Struts-side is obligatory.
>> But exactly, is a bad idea to use the capability of the container to
>> resolve EL expressions into values?
>> This is just an idea.
>
> Another thing, sorry for the noise :-D
>
> If EL Expressions are interpreted Struts-side, this means that in JSP
> tags the attributes that represent expressions should not be "rtexpr"
> activated.
> This means that they might not have an expression, so you cannot write:
> <struts:tag expression="${myexpr}" />
> because it is not interpreted as a string, but as an expression
> illegally placed.
> So you should do funny things, like string composition, to let it work.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Antonio Petrelli <an...@gmail.com>.
2009/11/3 Antonio Petrelli <an...@gmail.com>:
> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>> We also have FreeMarker , Velocity and we have a lot of expression
>> evaluations from Struts code itself.
>
> And in this case you're right, EL at Struts-side is obligatory.
> But exactly, is a bad idea to use the capability of the container to
> resolve EL expressions into values?
> This is just an idea.
Another thing, sorry for the noise :-D
If EL Expressions are interpreted Struts-side, this means that in JSP
tags the attributes that represent expressions should not be "rtexpr"
activated.
This means that they might not have an expression, so you cannot write:
<struts:tag expression="${myexpr}" />
because it is not interpreted as a string, but as an expression
illegally placed.
So you should do funny things, like string composition, to let it work.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Antonio Petrelli <an...@gmail.com>.
2009/11/3 Musachy Barroso <mu...@gmail.com>:
> We also have FreeMarker , Velocity and we have a lot of expression
> evaluations from Struts code itself.
And in this case you're right, EL at Struts-side is obligatory.
But exactly, is a bad idea to use the capability of the container to
resolve EL expressions into values?
This is just an idea.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
We also have FreeMarker , Velocity and we have a lot of expression
evaluations from Struts code itself.
musachy
On Tue, Nov 3, 2009 at 12:29 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2009/11/3 Musachy Barroso <mu...@gmail.com>:
>> I think I saw it in someone's blog but now I can't find it..did I make
>> this up? Anyway, I am out of pet projects, so I might just play with a
>> UEL plugin :)
>
> Is it really necessary? Isn't it possible to let EL be used by the container?
> In Tiles, in JSP support module, we solved the problem using two
> separated attributes, one for the expression (in OGNL, MVEL and EL
> [interpreted at Tiles-side]) and one for the value, that can be put
> either with a string value or with an EL expression.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Antonio Petrelli <an...@gmail.com>.
2009/11/3 Musachy Barroso <mu...@gmail.com>:
> I think I saw it in someone's blog but now I can't find it..did I make
> this up? Anyway, I am out of pet projects, so I might just play with a
> UEL plugin :)
Is it really necessary? Isn't it possible to let EL be used by the container?
In Tiles, in JSP support module, we solved the problem using two
separated attributes, one for the expression (in OGNL, MVEL and EL
[interpreted at Tiles-side]) and one for the value, that can be put
either with a string value or with an EL expression.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
I think I saw it in someone's blog but now I can't find it..did I make
this up? Anyway, I am out of pet projects, so I might just play with a
UEL plugin :)
musachy
On Mon, Nov 2, 2009 at 8:42 PM, Chris Pratt <th...@gmail.com> wrote:
> They've had static method calls for a long time, you just had to define them
> as Functions in the TLD. Have they added something else new?
> (*Chris*)
>
> On Mon, Nov 2, 2009 at 8:36 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> Thy are finally adding static method calls finally. I don't use any
>> advanced features from OGNL either, UEL would do just fine for me.
>>
>> On Mon, Nov 2, 2009 at 7:20 PM, Chris Pratt <th...@gmail.com>
>> wrote:
>> > I know it's not as sexy, but at this point I think I'd prefer plain old
>> JSTL
>> > EL to work globally. It's much easier to teach my junior programmers a
>> > single EL than have to explain where each is appropriate. But maybe
>> that's
>> > just me.
>> > (*Chris*)
>> >
>> > On Mon, Nov 2, 2009 at 7:06 PM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> Actually is not as far off as it sounds. Using the parameters-binder
>> >> branch and mvel branch in xwork you get a half working showcase. I
>> >> just need to get myself to do it :)
>> >>
>> >> musachy
>> >>
>> >> On Mon, Nov 2, 2009 at 6:14 PM, Chris Pratt <th...@gmail.com>
>> >> wrote:
>> >> > It would be sweeter if OGNL was optional in struts, but that topic has
>> >> been
>> >> > beaten to death. =8^(
>> >> > (*Chris*)
>> >> >
>> >> > On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> It would be sweet if javassist was optional in OGNL, specially
>> >> >> considering that we do not use it. I will resist the temptation to
>> >> >> vent my frustrations with OGNL here :) (and to fork it as well)
>> >> >>
>> >> >> musachy
>> >> >>
>> >> >> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <thechrispratt@gmail.com
>> >
>> >> >> wrote:
>> >> >> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3
>> with
>> >> >> > javassist-3.7.0.jar.
>> >> >> > (*Chris*)
>> >> >> >
>> >> >> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <musachy@gmail.com
>> >
>> >> >> wrote:
>> >> >> >
>> >> >> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
>> >> >> >> without Javassist? I get class loading errors without it. Please
>> note
>> >> >> >> that xwork contains an embedded version of javassist by mistake.
>> >> >> >>
>> >> >> >> musachy
>> >> >> >>
>> >> >> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <
>> >> thechrispratt@gmail.com>
>> >> >> >> wrote:
>> >> >> >> > That may be only for the compilation. I'm using it without
>> those
>> >> >> >> libraries
>> >> >> >> > and haven't had any problems.
>> >> >> >> > (*Chris*)
>> >> >> >> >
>> >> >> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <
>> >> musachy@gmail.com>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
>> >> >> jboss:javassist.
>> >> >> >> >>
>> >> >> >> >> musachy
>> >> >> >> >>
>> >> >> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
>> >> >> hermanns@aixcept.de>
>> >> >> >> >> wrote:
>> >> >> >> >> > +1, both make sense to wait for, cause the performance
>> >> improvement
>> >> >> >> >> > will satisfy lots of our users...
>> >> >> >> >> > That's the reason, why xwork is not yet released :)
>> >> >> >> >> >
>> >> >> >> >> > cheers,
>> >> >> >> >> > Rainer
>> >> >> >> >> >
>> >> >> >> >> >> Sounds good. It gives rainer some more time to get xwork
>> >> released.
>> >> >> >> >> >>
>> >> >> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >> >> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >> >> >> >> >>>> With the bytecode stuff out the way I am inclined to just
>> >> >> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >> >> >> >> >>>
>> >> >> >> >> >>> +1
>> >> >> >> >> >>>
>> >> >> >> >> >>> -Dale
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >> >>> For additional commands, e-mail:
>> dev-help@struts.apache.org
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> Wes Wannemacher
>> >> >> >> >> >> Author - Struts 2 In Practice
>> >> >> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery,
>> Sitemesh
>> >> and
>> >> >> >> more
>> >> >> >> >> >> http://www.manning.com/wannemacher
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > --
>> >> >> >> >> > Rainer Hermanns
>> >> >> >> >> > aixcept
>> >> >> >> >> > Willibrordstraße 82
>> >> >> >> >> > 52134 Herzogenrath - Germany
>> >> >> >> >> > w: http://aixcept.de/
>> >> >> >> >> > t: +49 - 2406 - 979 22 11
>> >> >> >> >> > f: +49 - 2406 - 979 22 13
>> >> >> >> >> > m: +49 - 170 - 343 29 12
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
They've had static method calls for a long time, you just had to define them
as Functions in the TLD. Have they added something else new?
(*Chris*)
On Mon, Nov 2, 2009 at 8:36 PM, Musachy Barroso <mu...@gmail.com> wrote:
> Thy are finally adding static method calls finally. I don't use any
> advanced features from OGNL either, UEL would do just fine for me.
>
> On Mon, Nov 2, 2009 at 7:20 PM, Chris Pratt <th...@gmail.com>
> wrote:
> > I know it's not as sexy, but at this point I think I'd prefer plain old
> JSTL
> > EL to work globally. It's much easier to teach my junior programmers a
> > single EL than have to explain where each is appropriate. But maybe
> that's
> > just me.
> > (*Chris*)
> >
> > On Mon, Nov 2, 2009 at 7:06 PM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> Actually is not as far off as it sounds. Using the parameters-binder
> >> branch and mvel branch in xwork you get a half working showcase. I
> >> just need to get myself to do it :)
> >>
> >> musachy
> >>
> >> On Mon, Nov 2, 2009 at 6:14 PM, Chris Pratt <th...@gmail.com>
> >> wrote:
> >> > It would be sweeter if OGNL was optional in struts, but that topic has
> >> been
> >> > beaten to death. =8^(
> >> > (*Chris*)
> >> >
> >> > On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com>
> >> wrote:
> >> >
> >> >> It would be sweet if javassist was optional in OGNL, specially
> >> >> considering that we do not use it. I will resist the temptation to
> >> >> vent my frustrations with OGNL here :) (and to fork it as well)
> >> >>
> >> >> musachy
> >> >>
> >> >> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <thechrispratt@gmail.com
> >
> >> >> wrote:
> >> >> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3
> with
> >> >> > javassist-3.7.0.jar.
> >> >> > (*Chris*)
> >> >> >
> >> >> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <musachy@gmail.com
> >
> >> >> wrote:
> >> >> >
> >> >> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
> >> >> >> without Javassist? I get class loading errors without it. Please
> note
> >> >> >> that xwork contains an embedded version of javassist by mistake.
> >> >> >>
> >> >> >> musachy
> >> >> >>
> >> >> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <
> >> thechrispratt@gmail.com>
> >> >> >> wrote:
> >> >> >> > That may be only for the compilation. I'm using it without
> those
> >> >> >> libraries
> >> >> >> > and haven't had any problems.
> >> >> >> > (*Chris*)
> >> >> >> >
> >> >> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <
> >> musachy@gmail.com>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
> >> >> jboss:javassist.
> >> >> >> >>
> >> >> >> >> musachy
> >> >> >> >>
> >> >> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
> >> >> hermanns@aixcept.de>
> >> >> >> >> wrote:
> >> >> >> >> > +1, both make sense to wait for, cause the performance
> >> improvement
> >> >> >> >> > will satisfy lots of our users...
> >> >> >> >> > That's the reason, why xwork is not yet released :)
> >> >> >> >> >
> >> >> >> >> > cheers,
> >> >> >> >> > Rainer
> >> >> >> >> >
> >> >> >> >> >> Sounds good. It gives rainer some more time to get xwork
> >> released.
> >> >> >> >> >>
> >> >> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> >> >> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
> >> >> >> >> >>>> With the bytecode stuff out the way I am inclined to just
> >> >> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
> >> >> >> >> >>>
> >> >> >> >> >>> +1
> >> >> >> >> >>>
> >> >> >> >> >>> -Dale
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> >>> For additional commands, e-mail:
> dev-help@struts.apache.org
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> Wes Wannemacher
> >> >> >> >> >> Author - Struts 2 In Practice
> >> >> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery,
> Sitemesh
> >> and
> >> >> >> more
> >> >> >> >> >> http://www.manning.com/wannemacher
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > --
> >> >> >> >> > Rainer Hermanns
> >> >> >> >> > aixcept
> >> >> >> >> > Willibrordstraße 82
> >> >> >> >> > 52134 Herzogenrath - Germany
> >> >> >> >> > w: http://aixcept.de/
> >> >> >> >> > t: +49 - 2406 - 979 22 11
> >> >> >> >> > f: +49 - 2406 - 979 22 13
> >> >> >> >> > m: +49 - 170 - 343 29 12
> >> >> >> >> >
> >> >> >> >> >
> >> >> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
Thy are finally adding static method calls finally. I don't use any
advanced features from OGNL either, UEL would do just fine for me.
On Mon, Nov 2, 2009 at 7:20 PM, Chris Pratt <th...@gmail.com> wrote:
> I know it's not as sexy, but at this point I think I'd prefer plain old JSTL
> EL to work globally. It's much easier to teach my junior programmers a
> single EL than have to explain where each is appropriate. But maybe that's
> just me.
> (*Chris*)
>
> On Mon, Nov 2, 2009 at 7:06 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> Actually is not as far off as it sounds. Using the parameters-binder
>> branch and mvel branch in xwork you get a half working showcase. I
>> just need to get myself to do it :)
>>
>> musachy
>>
>> On Mon, Nov 2, 2009 at 6:14 PM, Chris Pratt <th...@gmail.com>
>> wrote:
>> > It would be sweeter if OGNL was optional in struts, but that topic has
>> been
>> > beaten to death. =8^(
>> > (*Chris*)
>> >
>> > On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> It would be sweet if javassist was optional in OGNL, specially
>> >> considering that we do not use it. I will resist the temptation to
>> >> vent my frustrations with OGNL here :) (and to fork it as well)
>> >>
>> >> musachy
>> >>
>> >> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <th...@gmail.com>
>> >> wrote:
>> >> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
>> >> > javassist-3.7.0.jar.
>> >> > (*Chris*)
>> >> >
>> >> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
>> >> >> without Javassist? I get class loading errors without it. Please note
>> >> >> that xwork contains an embedded version of javassist by mistake.
>> >> >>
>> >> >> musachy
>> >> >>
>> >> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <
>> thechrispratt@gmail.com>
>> >> >> wrote:
>> >> >> > That may be only for the compilation. I'm using it without those
>> >> >> libraries
>> >> >> > and haven't had any problems.
>> >> >> > (*Chris*)
>> >> >> >
>> >> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <
>> musachy@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
>> >> jboss:javassist.
>> >> >> >>
>> >> >> >> musachy
>> >> >> >>
>> >> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
>> >> hermanns@aixcept.de>
>> >> >> >> wrote:
>> >> >> >> > +1, both make sense to wait for, cause the performance
>> improvement
>> >> >> >> > will satisfy lots of our users...
>> >> >> >> > That's the reason, why xwork is not yet released :)
>> >> >> >> >
>> >> >> >> > cheers,
>> >> >> >> > Rainer
>> >> >> >> >
>> >> >> >> >> Sounds good. It gives rainer some more time to get xwork
>> released.
>> >> >> >> >>
>> >> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >> >> >> >>>> With the bytecode stuff out the way I am inclined to just
>> >> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >> >> >> >>>
>> >> >> >> >>> +1
>> >> >> >> >>>
>> >> >> >> >>> -Dale
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> ---------------------------------------------------------------------
>> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Wes Wannemacher
>> >> >> >> >> Author - Struts 2 In Practice
>> >> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh
>> and
>> >> >> more
>> >> >> >> >> http://www.manning.com/wannemacher
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Rainer Hermanns
>> >> >> >> > aixcept
>> >> >> >> > Willibrordstraße 82
>> >> >> >> > 52134 Herzogenrath - Germany
>> >> >> >> > w: http://aixcept.de/
>> >> >> >> > t: +49 - 2406 - 979 22 11
>> >> >> >> > f: +49 - 2406 - 979 22 13
>> >> >> >> > m: +49 - 170 - 343 29 12
>> >> >> >> >
>> >> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
I know it's not as sexy, but at this point I think I'd prefer plain old JSTL
EL to work globally. It's much easier to teach my junior programmers a
single EL than have to explain where each is appropriate. But maybe that's
just me.
(*Chris*)
On Mon, Nov 2, 2009 at 7:06 PM, Musachy Barroso <mu...@gmail.com> wrote:
> Actually is not as far off as it sounds. Using the parameters-binder
> branch and mvel branch in xwork you get a half working showcase. I
> just need to get myself to do it :)
>
> musachy
>
> On Mon, Nov 2, 2009 at 6:14 PM, Chris Pratt <th...@gmail.com>
> wrote:
> > It would be sweeter if OGNL was optional in struts, but that topic has
> been
> > beaten to death. =8^(
> > (*Chris*)
> >
> > On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> It would be sweet if javassist was optional in OGNL, specially
> >> considering that we do not use it. I will resist the temptation to
> >> vent my frustrations with OGNL here :) (and to fork it as well)
> >>
> >> musachy
> >>
> >> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <th...@gmail.com>
> >> wrote:
> >> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
> >> > javassist-3.7.0.jar.
> >> > (*Chris*)
> >> >
> >> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com>
> >> wrote:
> >> >
> >> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
> >> >> without Javassist? I get class loading errors without it. Please note
> >> >> that xwork contains an embedded version of javassist by mistake.
> >> >>
> >> >> musachy
> >> >>
> >> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <
> thechrispratt@gmail.com>
> >> >> wrote:
> >> >> > That may be only for the compilation. I'm using it without those
> >> >> libraries
> >> >> > and haven't had any problems.
> >> >> > (*Chris*)
> >> >> >
> >> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <
> musachy@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
> >> jboss:javassist.
> >> >> >>
> >> >> >> musachy
> >> >> >>
> >> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
> >> hermanns@aixcept.de>
> >> >> >> wrote:
> >> >> >> > +1, both make sense to wait for, cause the performance
> improvement
> >> >> >> > will satisfy lots of our users...
> >> >> >> > That's the reason, why xwork is not yet released :)
> >> >> >> >
> >> >> >> > cheers,
> >> >> >> > Rainer
> >> >> >> >
> >> >> >> >> Sounds good. It gives rainer some more time to get xwork
> released.
> >> >> >> >>
> >> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> >> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
> >> >> >> >>>> With the bytecode stuff out the way I am inclined to just
> >> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
> >> >> >> >>>
> >> >> >> >>> +1
> >> >> >> >>>
> >> >> >> >>> -Dale
> >> >> >> >>>
> >> >> >> >>>
> >> >> ---------------------------------------------------------------------
> >> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Wes Wannemacher
> >> >> >> >> Author - Struts 2 In Practice
> >> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh
> and
> >> >> more
> >> >> >> >> http://www.manning.com/wannemacher
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Rainer Hermanns
> >> >> >> > aixcept
> >> >> >> > Willibrordstraße 82
> >> >> >> > 52134 Herzogenrath - Germany
> >> >> >> > w: http://aixcept.de/
> >> >> >> > t: +49 - 2406 - 979 22 11
> >> >> >> > f: +49 - 2406 - 979 22 13
> >> >> >> > m: +49 - 170 - 343 29 12
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
Actually is not as far off as it sounds. Using the parameters-binder
branch and mvel branch in xwork you get a half working showcase. I
just need to get myself to do it :)
musachy
On Mon, Nov 2, 2009 at 6:14 PM, Chris Pratt <th...@gmail.com> wrote:
> It would be sweeter if OGNL was optional in struts, but that topic has been
> beaten to death. =8^(
> (*Chris*)
>
> On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> It would be sweet if javassist was optional in OGNL, specially
>> considering that we do not use it. I will resist the temptation to
>> vent my frustrations with OGNL here :) (and to fork it as well)
>>
>> musachy
>>
>> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <th...@gmail.com>
>> wrote:
>> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
>> > javassist-3.7.0.jar.
>> > (*Chris*)
>> >
>> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
>> >> without Javassist? I get class loading errors without it. Please note
>> >> that xwork contains an embedded version of javassist by mistake.
>> >>
>> >> musachy
>> >>
>> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <th...@gmail.com>
>> >> wrote:
>> >> > That may be only for the compilation. I'm using it without those
>> >> libraries
>> >> > and haven't had any problems.
>> >> > (*Chris*)
>> >> >
>> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
>> jboss:javassist.
>> >> >>
>> >> >> musachy
>> >> >>
>> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
>> hermanns@aixcept.de>
>> >> >> wrote:
>> >> >> > +1, both make sense to wait for, cause the performance improvement
>> >> >> > will satisfy lots of our users...
>> >> >> > That's the reason, why xwork is not yet released :)
>> >> >> >
>> >> >> > cheers,
>> >> >> > Rainer
>> >> >> >
>> >> >> >> Sounds good. It gives rainer some more time to get xwork released.
>> >> >> >>
>> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >> >> >>>> With the bytecode stuff out the way I am inclined to just
>> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >> >> >>>
>> >> >> >>> +1
>> >> >> >>>
>> >> >> >>> -Dale
>> >> >> >>>
>> >> >> >>>
>> >> ---------------------------------------------------------------------
>> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Wes Wannemacher
>> >> >> >> Author - Struts 2 In Practice
>> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and
>> >> more
>> >> >> >> http://www.manning.com/wannemacher
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Rainer Hermanns
>> >> >> > aixcept
>> >> >> > Willibrordstraße 82
>> >> >> > 52134 Herzogenrath - Germany
>> >> >> > w: http://aixcept.de/
>> >> >> > t: +49 - 2406 - 979 22 11
>> >> >> > f: +49 - 2406 - 979 22 13
>> >> >> > m: +49 - 170 - 343 29 12
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
It would be sweeter if OGNL was optional in struts, but that topic has been
beaten to death. =8^(
(*Chris*)
On Mon, Nov 2, 2009 at 5:13 PM, Musachy Barroso <mu...@gmail.com> wrote:
> It would be sweet if javassist was optional in OGNL, specially
> considering that we do not use it. I will resist the temptation to
> vent my frustrations with OGNL here :) (and to fork it as well)
>
> musachy
>
> On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <th...@gmail.com>
> wrote:
> > Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
> > javassist-3.7.0.jar.
> > (*Chris*)
> >
> > On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> Chris, I wanted to double check on this, are you using Ognl 2.7.3
> >> without Javassist? I get class loading errors without it. Please note
> >> that xwork contains an embedded version of javassist by mistake.
> >>
> >> musachy
> >>
> >> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <th...@gmail.com>
> >> wrote:
> >> > That may be only for the compilation. I'm using it without those
> >> libraries
> >> > and haven't had any problems.
> >> > (*Chris*)
> >> >
> >> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com>
> >> wrote:
> >> >
> >> >> hum..there is one minor problem, ognl 2.7.3 depends on
> jboss:javassist.
> >> >>
> >> >> musachy
> >> >>
> >> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<
> hermanns@aixcept.de>
> >> >> wrote:
> >> >> > +1, both make sense to wait for, cause the performance improvement
> >> >> > will satisfy lots of our users...
> >> >> > That's the reason, why xwork is not yet released :)
> >> >> >
> >> >> > cheers,
> >> >> > Rainer
> >> >> >
> >> >> >> Sounds good. It gives rainer some more time to get xwork released.
> >> >> >>
> >> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> >> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
> >> >> >>>> With the bytecode stuff out the way I am inclined to just
> >> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
> >> >> >>>
> >> >> >>> +1
> >> >> >>>
> >> >> >>> -Dale
> >> >> >>>
> >> >> >>>
> >> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Wes Wannemacher
> >> >> >> Author - Struts 2 In Practice
> >> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and
> >> more
> >> >> >> http://www.manning.com/wannemacher
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Rainer Hermanns
> >> >> > aixcept
> >> >> > Willibrordstraße 82
> >> >> > 52134 Herzogenrath - Germany
> >> >> > w: http://aixcept.de/
> >> >> > t: +49 - 2406 - 979 22 11
> >> >> > f: +49 - 2406 - 979 22 13
> >> >> > m: +49 - 170 - 343 29 12
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
It would be sweet if javassist was optional in OGNL, specially
considering that we do not use it. I will resist the temptation to
vent my frustrations with OGNL here :) (and to fork it as well)
musachy
On Mon, Nov 2, 2009 at 4:42 PM, Chris Pratt <th...@gmail.com> wrote:
> Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
> javassist-3.7.0.jar.
> (*Chris*)
>
> On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> Chris, I wanted to double check on this, are you using Ognl 2.7.3
>> without Javassist? I get class loading errors without it. Please note
>> that xwork contains an embedded version of javassist by mistake.
>>
>> musachy
>>
>> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <th...@gmail.com>
>> wrote:
>> > That may be only for the compilation. I'm using it without those
>> libraries
>> > and haven't had any problems.
>> > (*Chris*)
>> >
>> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com>
>> wrote:
>> >
>> >> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
>> >>
>> >> musachy
>> >>
>> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
>> >> wrote:
>> >> > +1, both make sense to wait for, cause the performance improvement
>> >> > will satisfy lots of our users...
>> >> > That's the reason, why xwork is not yet released :)
>> >> >
>> >> > cheers,
>> >> > Rainer
>> >> >
>> >> >> Sounds good. It gives rainer some more time to get xwork released.
>> >> >>
>> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >> >>>> With the bytecode stuff out the way I am inclined to just
>> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >> >>>
>> >> >>> +1
>> >> >>>
>> >> >>> -Dale
>> >> >>>
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Wes Wannemacher
>> >> >> Author - Struts 2 In Practice
>> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and
>> more
>> >> >> http://www.manning.com/wannemacher
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Rainer Hermanns
>> >> > aixcept
>> >> > Willibrordstraße 82
>> >> > 52134 Herzogenrath - Germany
>> >> > w: http://aixcept.de/
>> >> > t: +49 - 2406 - 979 22 11
>> >> > f: +49 - 2406 - 979 22 13
>> >> > m: +49 - 170 - 343 29 12
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> > For additional commands, e-mail: dev-help@struts.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
Oops, I must not have looked close enough, I'm using OGNL 2.7.3 with
javassist-3.7.0.jar.
(*Chris*)
On Mon, Nov 2, 2009 at 3:39 PM, Musachy Barroso <mu...@gmail.com> wrote:
> Chris, I wanted to double check on this, are you using Ognl 2.7.3
> without Javassist? I get class loading errors without it. Please note
> that xwork contains an embedded version of javassist by mistake.
>
> musachy
>
> On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <th...@gmail.com>
> wrote:
> > That may be only for the compilation. I'm using it without those
> libraries
> > and haven't had any problems.
> > (*Chris*)
> >
> > On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
> >>
> >> musachy
> >>
> >> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
> >> wrote:
> >> > +1, both make sense to wait for, cause the performance improvement
> >> > will satisfy lots of our users...
> >> > That's the reason, why xwork is not yet released :)
> >> >
> >> > cheers,
> >> > Rainer
> >> >
> >> >> Sounds good. It gives rainer some more time to get xwork released.
> >> >>
> >> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> >> >>> Musachy Barroso <mu...@gmail.com> wrote:
> >> >>>> With the bytecode stuff out the way I am inclined to just
> >> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
> >> >>>
> >> >>> +1
> >> >>>
> >> >>> -Dale
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Wes Wannemacher
> >> >> Author - Struts 2 In Practice
> >> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and
> more
> >> >> http://www.manning.com/wannemacher
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Rainer Hermanns
> >> > aixcept
> >> > Willibrordstraße 82
> >> > 52134 Herzogenrath - Germany
> >> > w: http://aixcept.de/
> >> > t: +49 - 2406 - 979 22 11
> >> > f: +49 - 2406 - 979 22 13
> >> > m: +49 - 170 - 343 29 12
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
Chris, I wanted to double check on this, are you using Ognl 2.7.3
without Javassist? I get class loading errors without it. Please note
that xwork contains an embedded version of javassist by mistake.
musachy
On Mon, Jul 20, 2009 at 8:46 AM, Chris Pratt <th...@gmail.com> wrote:
> That may be only for the compilation. I'm using it without those libraries
> and haven't had any problems.
> (*Chris*)
>
> On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
>>
>> musachy
>>
>> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
>> wrote:
>> > +1, both make sense to wait for, cause the performance improvement
>> > will satisfy lots of our users...
>> > That's the reason, why xwork is not yet released :)
>> >
>> > cheers,
>> > Rainer
>> >
>> >> Sounds good. It gives rainer some more time to get xwork released.
>> >>
>> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> >>> Musachy Barroso <mu...@gmail.com> wrote:
>> >>>> With the bytecode stuff out the way I am inclined to just
>> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>> >>>
>> >>> +1
>> >>>
>> >>> -Dale
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >>> For additional commands, e-mail: dev-help@struts.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Wes Wannemacher
>> >> Author - Struts 2 In Practice
>> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
>> >> http://www.manning.com/wannemacher
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Rainer Hermanns
>> > aixcept
>> > Willibrordstraße 82
>> > 52134 Herzogenrath - Germany
>> > w: http://aixcept.de/
>> > t: +49 - 2406 - 979 22 11
>> > f: +49 - 2406 - 979 22 13
>> > m: +49 - 170 - 343 29 12
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
That may be only for the compilation. I'm using it without those libraries
and haven't had any problems.
(*Chris*)
On Mon, Jul 20, 2009 at 9:30 AM, Musachy Barroso <mu...@gmail.com> wrote:
> hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
>
> musachy
>
> On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de>
> wrote:
> > +1, both make sense to wait for, cause the performance improvement
> > will satisfy lots of our users...
> > That's the reason, why xwork is not yet released :)
> >
> > cheers,
> > Rainer
> >
> >> Sounds good. It gives rainer some more time to get xwork released.
> >>
> >> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> >>> Musachy Barroso <mu...@gmail.com> wrote:
> >>>> With the bytecode stuff out the way I am inclined to just
> >>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
> >>>
> >>> +1
> >>>
> >>> -Dale
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Wes Wannemacher
> >> Author - Struts 2 In Practice
> >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> >> http://www.manning.com/wannemacher
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > --
> > Rainer Hermanns
> > aixcept
> > Willibrordstraße 82
> > 52134 Herzogenrath - Germany
> > w: http://aixcept.de/
> > t: +49 - 2406 - 979 22 11
> > f: +49 - 2406 - 979 22 13
> > m: +49 - 170 - 343 29 12
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
hum..there is one minor problem, ognl 2.7.3 depends on jboss:javassist.
musachy
On Sun, Jul 19, 2009 at 11:32 PM, Rainer Hermanns<he...@aixcept.de> wrote:
> +1, both make sense to wait for, cause the performance improvement
> will satisfy lots of our users...
> That's the reason, why xwork is not yet released :)
>
> cheers,
> Rainer
>
>> Sounds good. It gives rainer some more time to get xwork released.
>>
>> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>>> Musachy Barroso <mu...@gmail.com> wrote:
>>>> With the bytecode stuff out the way I am inclined to just
>>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>>>
>>> +1
>>>
>>> -Dale
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> --
>> Wes Wannemacher
>> Author - Struts 2 In Practice
>> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
>> http://www.manning.com/wannemacher
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Rainer Hermanns
> aixcept
> Willibrordstraße 82
> 52134 Herzogenrath - Germany
> w: http://aixcept.de/
> t: +49 - 2406 - 979 22 11
> f: +49 - 2406 - 979 22 13
> m: +49 - 170 - 343 29 12
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Rainer Hermanns <he...@aixcept.de>.
+1, both make sense to wait for, cause the performance improvement
will satisfy lots of our users...
That's the reason, why xwork is not yet released :)
cheers,
Rainer
> Sounds good. It gives rainer some more time to get xwork released.
>
> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> Musachy Barroso <mu...@gmail.com> wrote:
>>> With the bytecode stuff out the way I am inclined to just
>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>>
>> +1
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Wes Wannemacher
> Author - Struts 2 In Practice
> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> http://www.manning.com/wannemacher
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Rainer Hermanns
aixcept
Willibrordstraße 82
52134 Herzogenrath - Germany
w: http://aixcept.de/
t: +49 - 2406 - 979 22 11
f: +49 - 2406 - 979 22 13
m: +49 - 170 - 343 29 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
yup, you have to get it from maven repo,
http://www.opensymphony.com/ognl/ works for me, but the download page
is empty anyway.
musachy
On Sat, Jul 18, 2009 at 8:35 PM, Dave Newton<ne...@yahoo.com> wrote:
> Chris Pratt wrote:
>>
>> I've been using ognl 2.7.2 for quite a while with no problems. But when I
>> saw you guys talking about 2.7.3, I decided to update my library and give
>> it
>> a try, but http://www.ognl.org seems to be gone and the download page on
>> http://www.opensymphony.com/ognl seems to be down as well. Is there
>> somewhere else I should be looking for the updated libraries?
>
> Can always get it from a Maven repo:
>
> http://mirrors.ibiblio.org/pub/mirrors/maven2/ognl/ognl/
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Dave Newton <ne...@yahoo.com>.
Chris Pratt wrote:
> I've been using ognl 2.7.2 for quite a while with no problems. But when I
> saw you guys talking about 2.7.3, I decided to update my library and give it
> a try, but http://www.ognl.org seems to be gone and the download page on
> http://www.opensymphony.com/ognl seems to be down as well. Is there
> somewhere else I should be looking for the updated libraries?
Can always get it from a Maven repo:
http://mirrors.ibiblio.org/pub/mirrors/maven2/ognl/ognl/
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Chris Pratt <th...@gmail.com>.
I've been using ognl 2.7.2 for quite a while with no problems. But when I
saw you guys talking about 2.7.3, I decided to update my library and give it
a try, but http://www.ognl.org seems to be gone and the download page on
http://www.opensymphony.com/ognl seems to be down as well. Is there
somewhere else I should be looking for the updated libraries?
(*Chris*)
On Sat, Jul 18, 2009 at 6:02 PM, Musachy Barroso <mu...@gmail.com> wrote:
> On Sat, Jul 18, 2009 at 5:43 PM, Musachy Barroso<mu...@gmail.com> wrote:
> > As a side note, I just noticed that trying to get a value from the
> > ValueStack, whose key(or an intermediate object in the expression)
> > does not exist is an expensive operation, because a new OgnlException
> > is thrown, even when it doesn't make it out of the value stack it is a
> > (unnecessary) performance hit, and it happens very, very often, I am
> > trying to figure out way to avoid it.
>
> meh...not fixable, I would have to do a change on OGNL code.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
On Sat, Jul 18, 2009 at 5:43 PM, Musachy Barroso<mu...@gmail.com> wrote:
> As a side note, I just noticed that trying to get a value from the
> ValueStack, whose key(or an intermediate object in the expression)
> does not exist is an expensive operation, because a new OgnlException
> is thrown, even when it doesn't make it out of the value stack it is a
> (unnecessary) performance hit, and it happens very, very often, I am
> trying to figure out way to avoid it.
meh...not fixable, I would have to do a change on OGNL code.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Musachy Barroso <mu...@gmail.com>.
committed. here are the tickets:
http://jira.opensymphony.com/browse/XW-710
https://issues.apache.org/struts/browse/WW-3198
Ognl 2.7.3 has a groupid of "ognl" instead of "opensymphony".
As a side note, I just noticed that trying to get a value from the
ValueStack, whose key(or an intermediate object in the expression)
does not exist is an expensive operation, because a new OgnlException
is thrown, even when it doesn't make it out of the value stack it is a
(unnecessary) performance hit, and it happens very, very often, I am
trying to figure out way to avoid it.
regards
musachy
On Sat, Jul 18, 2009 at 5:08 PM, Wes Wannemacher<we...@wantii.com> wrote:
> Sounds good. It gives rainer some more time to get xwork released.
>
> On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
>> Musachy Barroso <mu...@gmail.com> wrote:
>>> With the bytecode stuff out the way I am inclined to just
>>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>>
>> +1
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Wes Wannemacher
> Author - Struts 2 In Practice
> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> http://www.manning.com/wannemacher
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Wes Wannemacher <we...@wantii.com>.
Sounds good. It gives rainer some more time to get xwork released.
On 7/18/09, Dale Newfield <da...@newfield.org> wrote:
> Musachy Barroso <mu...@gmail.com> wrote:
>> With the bytecode stuff out the way I am inclined to just
>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>
> +1
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Dave Newton <ne...@yahoo.com>.
Dale Newfield wrote:
> Musachy Barroso <mu...@gmail.com> wrote:
>> With the bytecode stuff out the way I am inclined to just
>> upgrade to 2.7.3 at once, and upgrade freemarker also.
>
> +1
Also +1, and I'll have a bit of time this week.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ognl 2.7.3 performance
Posted by Dale Newfield <da...@newfield.org>.
Musachy Barroso <mu...@gmail.com> wrote:
> With the bytecode stuff out the way I am inclined to just
> upgrade to 2.7.3 at once, and upgrade freemarker also.
+1
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org