Can you explain to me why any EL needs to be in the struts.xml? I
understand how it's nice to pick up variable names for parameters, but
that's probably all OGNL should do -- and to be honest, you don't need OGNL
for that. Even the simplistic Commons BeanUtils can pull out values from
${...} expressions.On Wed, Sep 4, 2013 at 10:04 AM, Dave Newton <davelnew...@gmail.com> wrote: > There needs to be *something* inside the config file, although I'm leaning > towards something other than XML config, like Groovy/etc. instead of an EL, > but that's because I'm biased towards code. > > I've played a lot of useful games with OGNL inside resource files as well. > > This malleability is a nice feature; the issues have been around how deep > the EL can dig into the runtime. > > Dave > > > > On Wed, Sep 4, 2013 at 10:53 AM, Paul Benedict <pbened...@apache.org> > wrote: > > > IMO, I see no use for OGNL outside of the view layer. What good use cases > > are there to evluate OGNL in anything else? I also don't think it should > be > > used inside of struts.xml either. > > > > > > On Wed, Sep 4, 2013 at 9:50 AM, Cameron Morris <cmor...@part.net> wrote: > > > > > I'm an outsider here, but I thought I'd chime in on this. I'm > presenting > > > tomorrow night at an OWAP-chapter meeting on "Attacking and Defending > > > struts2" > http://prezi.com/yydldqt0dep-/attacking-and-defending-struts2/ > > > OGNL is the star of the show. (I'd love some feedback on the > > presentation > > > btw) > > > > > > OGNL is a big risk. OGNL in the jsps aren't as much an issue, it's the > > > OGNL use everywhere else as glue that seems to get us into trouble over > > and > > > over. We are planning on rewriting our public (non-authenticated) > > actions > > > as plain-old servlets just to reduce the exposure. > > > > > > Not for the risk, but for future flexibility, new pages we write will > be > > > JSP using only JSTL and EL. > > > > > > I haven't evaluated alternatives, but there appears to be many OSS > > > implementations of EL. For the parameterInterceptor it seems like OGNL > > > does too much and it just needs something simple enough to set values. > > > Perhaps a 1.1 version of JSTL-EL Perhaps we can roll our own that > does > > > just enough to set parameters. I'm curious to know if there are any > > > struts3 plans around this. I'm sorry to just offer criticism with no > > real > > > solution. > > > > > > > > > On Wed, Sep 4, 2013 at 7:53 AM, Christian Grobmeier < > grobme...@gmail.com > > > >wrote: > > > > > > > Am 04.09.13 15:41, schrieb Martin Gainty: > > > > > Granted OGNL is not intuitive but neither is JSTL > > > > > > > > > > because you don't understand something does not state the case for > > > > removal from the framework > > > > Not sure to whom you wrote this response. > > > > > > > > My problems with OGNL are: > > > > > > > > - not actively maintained (I am involved, I know about it) > > > > - hard to maintain > > > > - looks like it is / was responsible for a lot of security issues > > > > > > > > If "I" would not understand alone, it is really no reason to remove > > > > something from the framework. If a LOT of users do not understand > well, > > > > it is for sure. Frameworks today must be easy to understand and easy > to > > > > use. If we have a chance to to make things easier for users, we > should > > > > do it. > > > > > > > > In frontend land we might consider to propagate JSTL if our own > things > > > > cannot be maintained because lack of man power. > > > > > Please State your case for an alternative mechanism for accessing > > > > entities from the Object Graph > > > > > > > > > > Specific examples such as "OGNL access" vs "Alternative" access > could > > > > justify the refactoring effort > > > > I was asking to collect some input and see if there are similar > > feelings > > > > like I have on OGNL. > > > > > > > > > > > > > > Martin > > > > > ______________________________________________ > > > > > Verzicht und Vertraulichkeitanmerkung > > > > > > > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > > > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede > > > unbefugte > > > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese > > Nachricht > > > > dient lediglich dem Austausch von Informationen und entfaltet keine > > > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit > von > > > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > > > > > > > > > > > > > >> Subject: Re: Doubting OGNL > > > > >> To: dev@struts.apache.org > > > > >> From: umeshawas...@gmail.com > > > > >> Date: Wed, 4 Sep 2013 13:13:20 +0000 > > > > >> > > > > >> As per my experience over Stack Overflow, every alternate question > > on > > > > Struts2 is related to OGNL syntax or user is not able to understand > how > > > > OGNL working. > > > > >> > > > > >> I have a very good experience with JSTL and honestly I am more > than > > > > happy with its simple syntax. > > > > >> > > > > >> > > > > >> Sent from BlackBerryŽ on Airtel > > > > >> > > > > >> -----Original Message----- > > > > >> From: Christian Grobmeier <grobme...@gmail.com> > > > > >> Date: Wed, 04 Sep 2013 15:04:06 > > > > >> To: Struts Developers List<dev@struts.apache.org> > > > > >> Reply-To: "Struts Developers List" <dev@struts.apache.org> > > > > >> Subject: Doubting OGNL > > > > >> > > > > >> Folks, > > > > >> > > > > >> when researching on OGNL i found this link: > > > > >> > https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement > > > > >> > > > > >> In 2008 Brian mentioned "Security risks keep appearing" along with > > > OGNL > > > > >> and collected the places where we use OGNL. Given the recent > events > > I > > > > >> thought it might be good to bring this up again. Please also > note, I > > > > >> have helped with OGNLs incubation and I am also touchign it over > in > > > > >> Commons land. My impression is OGNL is not easy to understand and > > > there > > > > >> is not really much interest from other people to develop on it. > > > > >> > > > > >> Looking at this list I feel OGNL is pretty much tied to Struts. On > > the > > > > >> other hand we could start to slowly decouple the two. Not sure > what > > we > > > > >> should use otherwise. > > > > >> > > > > >> Any feelings on that? > > > > >> > > > > >> > > --------------------------------------------------------------------- > > > > >> 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 > > > > >> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > > > > > > > > > > > > > > > > -- > > Cheers, > > Paul > > > > > > -- > e: davelnew...@gmail.com > m: 908-380-8699 > s: davelnewton_skype > t: @dave_newton <https://twitter.com/dave_newton> > b: Bucky Bits <http://buckybits.blogspot.com/> > g: davelnewton <https://github.com/davelnewton> > so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton> > -- Cheers, Paul
