struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <>
Subject Re: [s2] OGNL abstracted (was Struts 2 and OGNL findings)
Date Tue, 11 Sep 2007 02:02:29 GMT
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.


On 9/11/07, James Holmes <> 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 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 []
> 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]
> On 9/8/07, Ted Husted <> 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 <> 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:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message