struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Lenz <br...@socialstrata.com>
Subject Re: AliasInterceptor parameter mapping issue
Date Fri, 28 Aug 2020 15:57:23 GMT
Thanks for the response, Yasser! Sure thing, I've created the bug here:

https://issues.apache.org/jira/browse/WW-5087

Best,

Brian

On Fri, Aug 28, 2020 at 8:56 AM Yasser Zamani <yasserzamani@apache.org>
wrote:

> Hi Brian,
>
> Sorry for inconvenience :( yes for me as well it looks like an
> unintentional bug introduced by [1].
>
> Thanks a lot for writing to us! To followup its resolution would you
> mind create a new JIRA ticket?
>
> Regards.
>
> [1]
>
> https://github.com/apache/struts/commit/787f2f96eb9f1bb3c8012ab42aa222ae6286a91a#diff-b7b7c87c1012088e79dcc5a7bd9e8127
>
> On 8/28/2020 4:58 AM, Brian Lenz wrote:
> > Hello,
> >
> > We are running into an issue with the AliasInterceptor after upgrading to
> > 2.5.22 (from 2.3.35). The issue is that the fallback behavior to look in
> > HttpParameters for a value guarantees a value will always be set and that
> > Evaluated.isDefined() will subsequently always return true. The issue is
> > that HttpParameters.get() *always* returns a non-null value. If there
> isn't
> > an explicit value set, then it returns a Parameter.Empty. This cascades
> > back to AliasInterceptor, which results in the empty value *always* being
> > set on the stack.
> >
> > As an example, let's say I have a parameter f with alias foo. If I set a
> > value for foo on the request, the behavior in AliasInterceptor will
> result
> > in an empty value being set for foo, thus overwriting the actual value
> > submitted.
> >
> > Is this the designed behavior? Based on the structure of the code, it
> > appears to be a bug since there is unnecessary logic otherwise
> > (specifically, the call to value.isDefined() on line 179). Further, this
> is
> > different behavior from the older versions of Struts
> (pre-HttpParameters).
> >
> > Instead, I would think that isDefined() should be checked on the
> > Parameter returned
> > from HttpParameters so that a non-null value is only set in the
> Evaluated if
> > the parameter is actually defined.
> >
> > Does anyone have any thoughts or insight into this issue? I looked in
> JIRA
> > and couldn't find anything related to it. Does anyone know of any
> > workarounds (aside from creating a custom AliasInterceptor to fix the
> > behavior)?
> >
> > Thanks!
> >
> > Brian
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message