|
»
ognl 2.7.3 performance
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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@...> 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@...> 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@...> >> 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@...> >> 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@...> >> >> 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 <dale@...> wrote: >> >> >>> Musachy Barroso <musachy@...> 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@... >> >> >>> For additional commands, e-mail: dev-help@... >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> -- >> >> >> 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@... >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > 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@... >> >> > For additional commands, e-mail: dev-help@... >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Chris Pratt
::
Rate this Message:
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 <musachy@...> 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@...> > 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@...> > 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@...> > >> 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@...> > >> 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@...> > >> >> 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 <dale@...> wrote: > >> >> >>> Musachy Barroso <musachy@...> 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@... > >> >> >>> For additional commands, e-mail: dev-help@... > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> 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@... > >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > -- > >> >> > 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@... > >> >> > For additional commands, e-mail: dev-help@... > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> For additional commands, e-mail: dev-help@... > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@... > >> For additional commands, e-mail: dev-help@... > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <thechrispratt@...> 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 <musachy@...> 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@...> >> 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@...> >> 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@...> >> >> 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@...> >> >> 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@...> >> >> >> 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 <dale@...> wrote: >> >> >> >>> Musachy Barroso <musachy@...> 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@... >> >> >> >>> For additional commands, e-mail: dev-help@... >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> 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@... >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > 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@... >> >> >> > For additional commands, e-mail: dev-help@... >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Chris Pratt
::
Rate this Message:
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 <musachy@...> 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 <thechrispratt@...> > 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 <musachy@...> > 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@...> > >> 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@...> > >> 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@...> > >> >> 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@...> > >> >> 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@...> > >> >> >> 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 <dale@...> wrote: > >> >> >> >>> Musachy Barroso <musachy@...> 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@... > >> >> >> >>> For additional commands, e-mail: dev-help@... > >> >> >> >>> > >> >> >> >>> > >> >> >> >> > >> >> >> >> > >> >> >> >> -- > >> >> >> >> 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@... > >> >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > 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@... > >> >> >> > For additional commands, e-mail: dev-help@... > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd > >> >> >> > >> >> >> > --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> For additional commands, e-mail: dev-help@... > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@... > >> For additional commands, e-mail: dev-help@... > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <thechrispratt@...> 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 <musachy@...> 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 <thechrispratt@...> >> 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 <musachy@...> >> 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@...> >> >> 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@...> >> >> 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@...> >> >> >> 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@...> >> >> >> 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@...> >> >> >> >> 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 <dale@...> wrote: >> >> >> >> >>> Musachy Barroso <musachy@...> 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@... >> >> >> >> >>> For additional commands, e-mail: dev-help@... >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> 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@... >> >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > 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@... >> >> >> >> > For additional commands, e-mail: dev-help@... >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Chris Pratt
::
Rate this Message:
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 <musachy@...> 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 <thechrispratt@...> > 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 <musachy@...> > 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 <thechrispratt@...> > >> 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 <musachy@...> > >> 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@... > > > >> >> 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@... > > > >> >> 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@...> > >> >> >> 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@...> > >> >> >> 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@...> > >> >> >> >> 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 <dale@...> wrote: > >> >> >> >> >>> Musachy Barroso <musachy@...> 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@... > >> >> >> >> >>> For additional commands, e-mail: > dev-help@... > >> >> >> >> >>> > >> >> >> >> >>> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> -- > >> >> >> >> >> 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@... > >> >> >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > 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@... > >> >> >> >> > For additional commands, e-mail: dev-help@... > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> -- > >> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd > >> >> >> >> > >> >> >> >> > >> --------------------------------------------------------------------- > >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> >> For additional commands, e-mail: dev-help@... > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscribe@... > >> >> For additional commands, e-mail: dev-help@... > >> >> > >> >> > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@... > >> For additional commands, e-mail: dev-help@... > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <thechrispratt@...> 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 <musachy@...> 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 <thechrispratt@...> >> 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 <musachy@...> >> 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 <thechrispratt@...> >> >> 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 <musachy@...> >> >> 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@... >> > >> >> >> 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@... >> > >> >> >> 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@...> >> >> >> >> 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@...> >> >> >> >> 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@...> >> >> >> >> >> 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 <dale@...> wrote: >> >> >> >> >> >>> Musachy Barroso <musachy@...> 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@... >> >> >> >> >> >>> For additional commands, e-mail: >> dev-help@... >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> 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@... >> >> >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > 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@... >> >> >> >> >> > For additional commands, e-mail: dev-help@... >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@... >> >> For additional commands, e-mail: dev-help@... >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Antonio Petrelli-3
::
Rate this Message:
2009/11/3 Musachy Barroso <musachy@...>:
> 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <antonio.petrelli@...> wrote: > 2009/11/3 Musachy Barroso <musachy@...>: >> 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@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Antonio Petrelli-3
::
Rate this Message:
2009/11/3 Musachy Barroso <musachy@...>:
> 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Antonio Petrelli-3
::
Rate this Message:
2009/11/3 Antonio Petrelli <antonio.petrelli@...>:
> 2009/11/3 Musachy Barroso <musachy@...>: >> 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <antonio.petrelli@...> wrote: > 2009/11/3 Antonio Petrelli <antonio.petrelli@...>: >> 2009/11/3 Musachy Barroso <musachy@...>: >>> 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@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Brian Pontarelli
::
Rate this Message:
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 > <antonio.petrelli@...> wrote: >> 2009/11/3 Antonio Petrelli <antonio.petrelli@...>: >>> 2009/11/3 Musachy Barroso <musachy@...>: >>>> 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@... >> For additional commands, e-mail: dev-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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@...> 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 >> <antonio.petrelli@...> wrote: >>> >>> 2009/11/3 Antonio Petrelli <antonio.petrelli@...>: >>>> >>>> 2009/11/3 Musachy Barroso <musachy@...>: >>>>> >>>>> 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@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Brian Pontarelli
::
Rate this Message:
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@... > > 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 >>> <antonio.petrelli@...> wrote: >>>> >>>> 2009/11/3 Antonio Petrelli <antonio.petrelli@...>: >>>>> >>>>> 2009/11/3 Musachy Barroso <musachy@...>: >>>>>> >>>>>> 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@... >>>> For additional commands, e-mail: dev-help@... >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <brian@...> 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 <brian@...> >> 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 >>>> <antonio.petrelli@...> wrote: >>>>> >>>>> 2009/11/3 Antonio Petrelli <antonio.petrelli@...>: >>>>>> >>>>>> 2009/11/3 Musachy Barroso <musachy@...>: >>>>>>> >>>>>>> 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@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Antonio Petrelli-3
::
Rate this Message:
2009/11/3 Musachy Barroso <musachy@...>:
> 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <antonio.petrelli@...> wrote: > 2009/11/3 Musachy Barroso <musachy@...>: >> 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@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <musachy@...> 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 > <antonio.petrelli@...> wrote: >> 2009/11/3 Musachy Barroso <musachy@...>: >>> 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@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: ognl 2.7.3 performance
by Musachy Barroso
::
Rate this Message:
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 <musachy@...> 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@... For additional commands, e-mail: dev-help@... |
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
