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 <yasserzam...@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-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
