When working within JSPs, OGNL feels out of place after using the standard
tag libraries and EL for so long. Using OGNL in JSP also limits the use of
existing tag libraries that are built using EL without some type of
javax.el.ELResolver that can access the ValueStack or the Action for the
request. In practice this leads to the mixing of OGNL and EL on the same
page and it can be hard to keep track of what scope (EL or ValueStack) the
bean or variable resides. I have stopped counting how many times I start
to type "${…}" in a tag to realize that I'm using a Struts tag that doesn't
support EL. This may also be the reason why the "%{…}" syntax is used
heavily. I haven't used Freemarker or Velocity views so I don't know if
there is the same feeling there or not.
Having one syntax for accessing runtime information is very desirable.
Java EE and SpringFramework both maintain their own expression languages.
Moving from OGNL to the javax.el.* APIs doesn't address several major
concerns. The API would still be out of the control of the Struts project
since this is provided by the servlet container. As others have noted, the
way Struts uses OGNL can be adjusted so that there are more constraints
like using a SecurityManager and providing some sort of sandboxing to the
ValueStack that would limit expressions to accessing the current Action
during parameter binding for instance.
>From an application developer perspective, I would probably use EL 3.0 for
new projects. What new Struts framework features would be available if EL
3.0 was adopted? What features would be lost?
Struts Enhancements:
Better integration with JSP views
Deferred Value expressions (evaluate now vs. evaluate later)
Struts Regressions:
Backward Compatibility - EL and OGNL might have the similar features but
they have different syntax
Increased container dependency
On Fri, Sep 6, 2013 at 1:08 AM, Lukasz Lenart <lukaszlen...@apache.org>wrote:
> I'm not saying that users can't have other options - and have few
> support for few ELs is a nice idea and bad as well - more to support
> ;-)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> 2013/9/5 Steven Benitez <steven.beni...@gmail.com>:
> > I support EL3 over OGNL, but I realize this will be an uphill battle.
> I've
> > used Struts2/Webwork with EL for years and I can continue to do that on
> my
> > own.
> >
> >
> > On Thu, Sep 5, 2013 at 3:22 PM, Lukasz Lenart <lukaszlen...@apache.org
> >wrote:
> >
> >> 2013/9/5 Christian Grobmeier <grobme...@gmail.com>:
> >> > Am 05.09.13 20:43, schrieb Lukasz Lenart:
> >> >> Guys,
> >> >>
> >> >> are you serious? are you blaming OGNL? the hammer? 100% of
> >> >> vulnerability related to OGNL was our - developers - fault. We did
> use
> >> >> (and still do) the hammer in inappropriate way. Changing hammer is
> not
> >> >> the solution!
> >> > The hammer is stuck at Apache Commons. Nobody of us Struts devs has
> >> > managed to make a release of it.
> >> > Honestely OGNL codebase is a mess and we are short on man power.
> >>
> >> Maybe a mess but anyway OGNL is very powerful - there was not enough
> >> rumour but I think with S3 ahead is the way to go. I think what's left
> >> to do is review all the TODOs and logging layer. TODOs are already on
> >> my list.
> >>
> >> > Maybe we use it wrong. Then please lets fix it. Still the problem
> >> > remains that we are using something which we don't control. It is also
> >> > unlikely that we fix it in Commons-land the next time.
> >>
> >> Nah... I have another pull-request to the old OGNL which was already
> >> solved in the Commons-OGNL - it just shows that the OGNL code base is
> >> very mature and ready to be released.
> >>
> >> > To stick with your nice analogy - do we really need to solve a
> problems
> >> > which requires a hammer? Or is something smaller efficient in the same
> >> > way and maybe safer by default?
> >>
> >> Maybe not, I don't know. But changing know hammer to unknown hammer
> >> isn't the way to go - as for me :-)
> >>
> >> >> Things related to ${} or %{} should be clarified - %{} is called an
> >> >> alternative syntax in the source ;-) It should be removed and we
> >> >> should stick just to ${} - maybe it can be useful in XMLs as far I
> >> >> know '$' isn't an allowed value - maybe something else can be used.
> >> > This would fix one problem of many. But the more serious question is:
> >> > how can we make Struts more secure? If we use it wrong, then lets try
> to
> >> > make it good. I will interview Rene on the security manager option
> which
> >> > was mentioned earlier in this thread.
> >>
> >> How? Use the Java SecurityManager :-) Really, that was the answer of
> >> one of the Tomcat's creator. If you want a fully secure Java based
> >> application stick with what Java provides - don't invent the wheel!
> >>
> >>
> >> Kind regards
> >> Ł
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> >> For additional commands, e-mail: dev-h...@struts.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
