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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to