You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2007/09/08 16:50:29 UTC
[s2] OGNL abstracted (was Struts 2 and OGNL findings)
Ok, so take that last bit I said about wanting to keep with OGNL tied
throughout our code and scrap it. I've just finished the first step
in a major refactoring of our OGNL usage, both in XWork and Struts,
and have found a way to put all code that references OGNL in any way
in its own package, and any code that referenced those packages
changed to use a new reflection/EL abstraction layer. The end result
is a handful of interfaces that you'd need to implement if you wanted
to use another EL - i.e. switchable expression languages [1]
The following new packages would be created:
com.opensymphony.xwork2.ognl
com.opensymphony.xwork2.ognl.accessors
com.opensymphony.xwork.util.reflection
The good part about this refactoring is it should have little impact
on end user code, and fit into our minor release definition nicely.
Say what you will about ognl, it is pretty well-designed from an API
independence standpoint, which really helped.
My next steps are to move the tests around accordingly, do some
general cleanups like Javadocs, and perform more testing.
Did we have any concrete performance or resource benchmarks involving
OGNL? If so, after this, I'd love to see a different EL put in there
to see if we really get any performance boost. Also, this refactoring
helped identify areas we use OGNL a lot but probably don't really need
to, so even if we stick with it, we could optimize our usage of it.
Any objections before I finish it up and commit it?
Don
[1] https://issues.apache.org/struts/browse/WW-1566
On 9/8/07, Ted Husted <hu...@apache.org> wrote:
> Thanks so much, Don. OGNL has been a point of concern, and I'm glad
> you were able to look into it.
>
> With TP5 moving away from OGNL, do we know of any other projects other
> than XW still using it?
>
> If not, then if we (meaning XW) starts to tweak OGNL, would it make
> sense to bring OGNL into the XW codebase, eliminating a dependency?
>
> -Ted.
>
> On 9/7/07, Don Brown <mr...@twdata.org> wrote:
> > I spent the last couple days looking into the OGNL situation in Struts
> > 2 and XWork, with the intent on if not eliminating it, at least
> > blocking it cleanly off.
>
> ---------------------------------------------------------------------
> 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: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Blake Byrnes <bl...@gmail.com>.
Does UEL have better generics support? Using generics with Struts 2 actions
or models (or anything OGNL needs to interact with) is fairly difficult
right now. I've also found OGNL to be pretty much a mystery anytime I need
to do anything new (this could be more a matter of spitting out more
relevant information when errors occur).
On Fri, Feb 15, 2008 at 6:38 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Mon, Sep 10, 2007 at 7:02 PM, Don Brown <mr...@twdata.org> wrote:
> > I guess you really don't know until you benchmark it,
> ...
> > As far as a replacement, personally, I'm more interested in
> > incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> > older servlet containers. It may even be possible to put OGNL behind
> > the Unified EL API, allowing us to code to a standard and allow the
> > user to fully swap the EL.
>
> Did anything ever happen with this? Can you switch to a different EL
> in Struts 2.1?
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
I started an "Issues" section and a "Goals" section to explicitly
identify the problem(s) that needs to be solved.
http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
Brian Pontarelli wrote:
> Yeah, this is one of the frustrations that most beginners encounter
> and that I'd really like to fix. I'd say it should be ${} or #{} so
> that it is the same notation in JSPs, XML, etc. In fact, I would think
> that it would make the most sense to follow the UEL convention such
> that ${} is immediately evaluated and #{} is evaluated later. So, in
> the case of XML and annotations, it would probably be #{} to follow
> the standard. Furthermore, you should be able to use ${} in XML and
> annotations and it is resolved immediately. This would be useful for
> servlet context values (context path, etc), statics, and other types
> of configuration.
>
> If anyone wants to help catalog all the OGNL usages, this will be the
> first step in getting this stuff changed. I started a wiki page to
> track all this information:
>
> http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
>
> -bp
>
>
> Dale Newfield wrote:
>> Brian Pontarelli wrote:
>>> I've been trying to catalog all of the cases where OGNL exists and
>>> where it can be replaced.
>>
>> Since different ELs specify different mechanisms to state "this is an
>> expression to be evaluated", I wonder what we should do about the
>> delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
>>
>> Right now in result specifications in struts.xml (when the result
>> supports it, and when parsed) we use ${} to say "this is an
>> expression to be evaluated" even though it's currently ognl (which
>> uses %{}). I'm of several thoughts regarding this. One one hand
>> since it's OGNL I think it should be %{}. On the other hand if we're
>> contemplating switching ELs maybe it should not be EL-specific so
>> that the EL can be changed without modifying all the expressions.
>>
>> So: Is it possible to have these change with the EL? Is it
>> desirable? If we want to use a single type for all ELs, which should
>> it be?
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Brian Pontarelli <br...@pontarelli.com>.
Yeah, this is one of the frustrations that most beginners encounter and
that I'd really like to fix. I'd say it should be ${} or #{} so that it
is the same notation in JSPs, XML, etc. In fact, I would think that it
would make the most sense to follow the UEL convention such that ${} is
immediately evaluated and #{} is evaluated later. So, in the case of XML
and annotations, it would probably be #{} to follow the standard.
Furthermore, you should be able to use ${} in XML and annotations and it
is resolved immediately. This would be useful for servlet context values
(context path, etc), statics, and other types of configuration.
If anyone wants to help catalog all the OGNL usages, this will be the
first step in getting this stuff changed. I started a wiki page to track
all this information:
http://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
-bp
Dale Newfield wrote:
> Brian Pontarelli wrote:
>> I've been trying to catalog all of the cases where OGNL exists and
>> where it can be replaced.
>
> Since different ELs specify different mechanisms to state "this is an
> expression to be evaluated", I wonder what we should do about the
> delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
>
> Right now in result specifications in struts.xml (when the result
> supports it, and when parsed) we use ${} to say "this is an expression
> to be evaluated" even though it's currently ognl (which uses %{}).
> I'm of several thoughts regarding this. One one hand since it's OGNL
> I think it should be %{}. On the other hand if we're contemplating
> switching ELs maybe it should not be EL-specific so that the EL can be
> changed without modifying all the expressions.
>
> So: Is it possible to have these change with the EL? Is it
> desirable? If we want to use a single type for all ELs, which should
> it be?
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Dale Newfield <Da...@Newfield.org>.
Brian Pontarelli wrote:
> I've been trying to catalog all of the cases where OGNL exists and where
> it can be replaced.
Since different ELs specify different mechanisms to state "this is an
expression to be evaluated", I wonder what we should do about the
delineating characters "%{"/"}" vs. "${"/"}" vs. "#{"/"}", etc.
Right now in result specifications in struts.xml (when the result
supports it, and when parsed) we use ${} to say "this is an expression
to be evaluated" even though it's currently ognl (which uses %{}). I'm
of several thoughts regarding this. One one hand since it's OGNL I
think it should be %{}. On the other hand if we're contemplating
switching ELs maybe it should not be EL-specific so that the EL can be
changed without modifying all the expressions.
So: Is it possible to have these change with the EL? Is it desirable?
If we want to use a single type for all ELs, which should it be?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Brian Pontarelli <br...@pontarelli.com>.
I've been trying to catalog all of the cases where OGNL exists and where
it can be replaced. I'll sometime in the next few weeks to really work
on this and I'm hoping that we can replace OGNL from all developer
facing locations and completely standardize on EL. I think most folks
would be in favor of making things simpler and more standard across all
layers of Struts, including JSPs.
From what I've found thus far, I think the main point where OGNL is
extremely useful and something similar to OGNL is required is the
parameter handling. Other than that, it is just a matter of changing
code and possibly losing some features such as inline list and map
creation (not sure if UEL has this or not).
-bp
Jeromy Evans wrote:
> Wendy Smoak wrote:
>> Did anything ever happen with this? Can you switch to a different EL
>> in Struts 2.1?
>>
>>
> Hi Wendy,
> Not at this point. A plugin has been started in the sandbox
> (struts2-uel-plugin). However, my impression in that OGNL is deeply
> entrenched and making the EL switchable is a major undertaking. For a
> start, the Component, which every tag extends, has numerous methods
> that have been assumed to evaluate OGNL to access the valuestack (eg.
> findString) and the default converters all seem to fall-back to OGNL
> to determine object types. These can be made EL-independent, or OGNL
> wrapped so UEL can be used in the tags, but it's not going to be easy!
>
> See the thread(s) from November 07 containing "JUEL plugin" in the
> subject
>
> reagrds,
> Jeromy Evans
>
> ---------------------------------------------------------------------
> 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: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Wendy Smoak wrote:
> Did anything ever happen with this? Can you switch to a different EL
> in Struts 2.1?
>
>
Hi Wendy,
Not at this point. A plugin has been started in the sandbox
(struts2-uel-plugin). However, my impression in that OGNL is deeply
entrenched and making the EL switchable is a major undertaking. For a
start, the Component, which every tag extends, has numerous methods that
have been assumed to evaluate OGNL to access the valuestack (eg.
findString) and the default converters all seem to fall-back to OGNL to
determine object types. These can be made EL-independent, or OGNL
wrapped so UEL can be used in the tags, but it's not going to be easy!
See the thread(s) from November 07 containing "JUEL plugin" in the subject
reagrds,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Wendy Smoak <ws...@gmail.com>.
On Mon, Sep 10, 2007 at 7:02 PM, Don Brown <mr...@twdata.org> wrote:
> I guess you really don't know until you benchmark it,
...
> As far as a replacement, personally, I'm more interested in
> incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> older servlet containers. It may even be possible to put OGNL behind
> the Unified EL API, allowing us to code to a standard and allow the
> user to fully swap the EL.
Did anything ever happen with this? Can you switch to a different EL
in Struts 2.1?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Paul Benedict <pb...@apache.org>.
Henri also is fixing a lot of outstanding EL bugs in the taglibs project.
On 9/11/07, Antonio Petrelli <an...@gmail.com> wrote:
>
> 2007/9/11, Don Brown <mr...@twdata.org>:
> >
> > As far as a replacement, personally, I'm more interested in
> > incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> > older servlet containers. It may even be possible to put OGNL behind
> > the Unified EL API, allowing us to code to a standard and allow the
> > user to fully swap the EL.
>
>
>
> In this case, the JUEL project can be taken as a start:
> http://juel.sourceforge.net/
>
> Antonio
>
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/9/11, Don Brown <mr...@twdata.org>:
>
> As far as a replacement, personally, I'm more interested in
> incorporating the "Unified EL", standardized by JSP 2.1 but usable by
> older servlet containers. It may even be possible to put OGNL behind
> the Unified EL API, allowing us to code to a standard and allow the
> user to fully swap the EL.
In this case, the JUEL project can be taken as a start:
http://juel.sourceforge.net/
Antonio
Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by Don Brown <mr...@twdata.org>.
I guess you really don't know until you benchmark it, but I'm a bit
skeptical that compiling and caching all OGNL expressions is going to
be the silver bullet. First, I wonder if the queries are similar
enough that it would make a big difference, and would we now be eating
up a significant portion of resources keeping those cached instances
in memory?
As far as a replacement, personally, I'm more interested in
incorporating the "Unified EL", standardized by JSP 2.1 but usable by
older servlet containers. It may even be possible to put OGNL behind
the Unified EL API, allowing us to code to a standard and allow the
user to fully swap the EL.
Don
On 9/11/07, James Holmes <ja...@jamesholmes.com> wrote:
> I meant to respond to this sooner, but forgot. Your last email reminded me.
>
> This is great news. Perhaps now is the time to implement the OGNL 2.7
> performance enhancements. From what I could make of following some threads
> (here and on TheServerSide.com) MVEL is not necessarily any faster than OGNL
> (and maybe slower) once you implement the new OGNL compilation of
> expressions code.
>
> Did you follow any of those performance threads Don? Do you have the
> knowledge and/or interest to implement that? I don't have the knowledge
> myself, but think it would be a huge win for Struts 2. I can dig up the
> threads and related info you want me to. I know the OGNL guy offered to help
> the Struts 2 devs with implementing the improvements.
>
> James
>
>
> -----Original Message-----
> From: Don Brown [mailto:mrdon@twdata.org]
> Sent: Saturday, September 08, 2007 10:50 AM
> To: Struts Developers List
> Subject: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
>
> Ok, so take that last bit I said about wanting to keep with OGNL tied
> throughout our code and scrap it. I've just finished the first step
> in a major refactoring of our OGNL usage, both in XWork and Struts,
> and have found a way to put all code that references OGNL in any way
> in its own package, and any code that referenced those packages
> changed to use a new reflection/EL abstraction layer. The end result
> is a handful of interfaces that you'd need to implement if you wanted
> to use another EL - i.e. switchable expression languages [1]
>
> The following new packages would be created:
>
> com.opensymphony.xwork2.ognl
> com.opensymphony.xwork2.ognl.accessors
> com.opensymphony.xwork.util.reflection
>
> The good part about this refactoring is it should have little impact
> on end user code, and fit into our minor release definition nicely.
> Say what you will about ognl, it is pretty well-designed from an API
> independence standpoint, which really helped.
>
> My next steps are to move the tests around accordingly, do some
> general cleanups like Javadocs, and perform more testing.
>
> Did we have any concrete performance or resource benchmarks involving
> OGNL? If so, after this, I'd love to see a different EL put in there
> to see if we really get any performance boost. Also, this refactoring
> helped identify areas we use OGNL a lot but probably don't really need
> to, so even if we stick with it, we could optimize our usage of it.
>
> Any objections before I finish it up and commit it?
>
> Don
>
> [1] https://issues.apache.org/struts/browse/WW-1566
>
> On 9/8/07, Ted Husted <hu...@apache.org> wrote:
> > Thanks so much, Don. OGNL has been a point of concern, and I'm glad
> > you were able to look into it.
> >
> > With TP5 moving away from OGNL, do we know of any other projects other
> > than XW still using it?
> >
> > If not, then if we (meaning XW) starts to tweak OGNL, would it make
> > sense to bring OGNL into the XW codebase, eliminating a dependency?
> >
> > -Ted.
> >
> > On 9/7/07, Don Brown <mr...@twdata.org> wrote:
> > > I spent the last couple days looking into the OGNL situation in Struts
> > > 2 and XWork, with the intent on if not eliminating it, at least
> > > blocking it cleanly off.
> >
> > ---------------------------------------------------------------------
> > 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: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Posted by James Holmes <ja...@jamesholmes.com>.
I meant to respond to this sooner, but forgot. Your last email reminded me.
This is great news. Perhaps now is the time to implement the OGNL 2.7
performance enhancements. From what I could make of following some threads
(here and on TheServerSide.com) MVEL is not necessarily any faster than OGNL
(and maybe slower) once you implement the new OGNL compilation of
expressions code.
Did you follow any of those performance threads Don? Do you have the
knowledge and/or interest to implement that? I don't have the knowledge
myself, but think it would be a huge win for Struts 2. I can dig up the
threads and related info you want me to. I know the OGNL guy offered to help
the Struts 2 devs with implementing the improvements.
James
-----Original Message-----
From: Don Brown [mailto:mrdon@twdata.org]
Sent: Saturday, September 08, 2007 10:50 AM
To: Struts Developers List
Subject: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Ok, so take that last bit I said about wanting to keep with OGNL tied
throughout our code and scrap it. I've just finished the first step
in a major refactoring of our OGNL usage, both in XWork and Struts,
and have found a way to put all code that references OGNL in any way
in its own package, and any code that referenced those packages
changed to use a new reflection/EL abstraction layer. The end result
is a handful of interfaces that you'd need to implement if you wanted
to use another EL - i.e. switchable expression languages [1]
The following new packages would be created:
com.opensymphony.xwork2.ognl
com.opensymphony.xwork2.ognl.accessors
com.opensymphony.xwork.util.reflection
The good part about this refactoring is it should have little impact
on end user code, and fit into our minor release definition nicely.
Say what you will about ognl, it is pretty well-designed from an API
independence standpoint, which really helped.
My next steps are to move the tests around accordingly, do some
general cleanups like Javadocs, and perform more testing.
Did we have any concrete performance or resource benchmarks involving
OGNL? If so, after this, I'd love to see a different EL put in there
to see if we really get any performance boost. Also, this refactoring
helped identify areas we use OGNL a lot but probably don't really need
to, so even if we stick with it, we could optimize our usage of it.
Any objections before I finish it up and commit it?
Don
[1] https://issues.apache.org/struts/browse/WW-1566
On 9/8/07, Ted Husted <hu...@apache.org> wrote:
> Thanks so much, Don. OGNL has been a point of concern, and I'm glad
> you were able to look into it.
>
> With TP5 moving away from OGNL, do we know of any other projects other
> than XW still using it?
>
> If not, then if we (meaning XW) starts to tweak OGNL, would it make
> sense to bring OGNL into the XW codebase, eliminating a dependency?
>
> -Ted.
>
> On 9/7/07, Don Brown <mr...@twdata.org> wrote:
> > I spent the last couple days looking into the OGNL situation in Struts
> > 2 and XWork, with the intent on if not eliminating it, at least
> > blocking it cleanly off.
>
> ---------------------------------------------------------------------
> 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