Am 04.09.13 17:10, schrieb Paul Benedict:
> 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.
BeanUtils 2 also is worth a look.
Actually BU might be a nice idea for use inside the frontend layer.
I am not sure why we need it in struts.xml, but I guess its because of
something like that:
<result type="stream">
<param name="contentType">application/pdf</param>
<param name="inputName">pdfStream</param>
<param name="contentDisposition">attachment;
filename="${fileName}"</param>
<param name="bufferSize">1024</param>
</result>
(note the ${fileName}
That said, with the idea of making the Convention plugin a first class
citizen in S3, suggesting Groovy/etc like configuration might make sense
too. This would reduce the need of OGNL a lot I guess.
>
> 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>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
