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/11/03 00:39:36 UTC

Re: ognl 2.7.3 performance

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>.
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
>
>