I prefer EL over OGNL, but the problem with removing OGNL in Struts 3 would be that there isn't currently (that I am aware of) a way to use EL within Velocity, FreeMarker, Thymleaf, etc. Not everyone uses JSP.
Someone could probably create ElValueStack and ElValueStackFactory implementations. OGNL is also used for the framework's type conversion. On Wed, Sep 4, 2013 at 2:04 PM, Doug Erickson <erick...@part.net> wrote: > A lot of my feelings about OGNL are summed up in a StackOverflow answer of > mine: > > > http://stackoverflow.com/a/**341597/3474<http://stackoverflow.com/a/341597/3474> > > A couple of points from there I'd like to stress: > > JSTL and OGNL are not comparable. A few people have mentioned JSTL today, > but hopefully they were talking about EL. More precision with these terms > would clarify the discussion. > > EL is supported by the container. It works with any framework. As a JEE > spec, tool support for EL is also better (i.e., it exists). > > Ten or twelve years ago, OGNL was a defensible choice to fulfill an unmet > need, but now we have EL. I would question whether any great deliberation > went into WebWork's original adoption of OGNL. I'm curious if Struts2 > developers remember if the issue was considered when adopting WebWork. > > My ideal is that you shouldn't be able to tell what framework is used on > the server just by looking at the JSPs. Obviously, enforcing that in > Struts2 would be too disruptive, but it's a practice that developers can > choose voluntarily in the view layer. > > What can we do to restrict and harden the non-view components against > these crippling OGNL-based vulnerabilities? > > On 09/04/2013 07:04 AM, Christian Grobmeier wrote: > >> Folks, >> > > ... > > My impression is OGNL is not easy to understand and there >> is not really much interest from other people to develop on it. >> > > ... > > Any feelings on that? >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@struts.apache.**org<dev-unsubscr...@struts.apache.org> > For additional commands, e-mail: dev-h...@struts.apache.org > >
