Mailing-List: contact issues-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@struts.apache.org
Date: Wed, 12 Oct 2016 14:41:21 +0000 (UTC)
From: "Lukasz Lenart (JIRA)" <jira@apache.org>
To: issues@struts.apache.org
Message-ID: <JIRA.12992256.1469449850000.805388.1476283281382@Atlassian.JIRA>
In-Reply-To: <JIRA.12992256.1469449850000@Atlassian.JIRA>
References: <JIRA.12992256.1469449850000@Atlassian.JIRA> <JIRA.12992256.1469449850610@arcas>
Subject: [jira] [Closed] (WW-4668) Issue with Struts2 Request Parameters
 after update to Struts 2.3.29
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 12 Oct 2016 14:41:25 -0000


     [ https://issues.apache.org/jira/browse/WW-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukasz Lenart closed WW-4668.
-----------------------------

> Issue with Struts2 Request Parameters after update to Struts 2.3.29
> -------------------------------------------------------------------
>
>                 Key: WW-4668
>                 URL: https://issues.apache.org/jira/browse/WW-4668
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Value Stack
>    Affects Versions: 2.3.28, 2.3.29, 2.3.30
>            Reporter: Marco Czollmann
>             Fix For: 2.3.28
>
>
> Hello Struts Team,
> we updated from Struts 2.3.24.x to 2.3.29.
> We realized that we got some problems with parameters getting set into our Java actions. We are using Lombok to create getters and setters.
> Example: 
> {code:java}
>   @Getter
>   @Setter
>   private String sSearch_contentTypeId;
> {code}
> This results in a generated setter name "setSSearch_contentTypeId".
> With the Struts Version below 2.3.28, which used OGNL 3.0.6 this was no problem. With the latest Version of OGNL, 3.0.17, included since 2.3.28 of Struts, this setter is no longer found.
> Reason for this is a change within the OGNL Code in "OgnlRuntime.java".
> Old Line 1774:
> {code:java}
> String baseName = Character.toUpperCase(propertyName.charAt(0)) + propertyName.substring(1);
> {code}
> New Line 1871:
> {code:java}
> String baseName = capitalizeBeanPropertyName(propertyName);
> {code}
> This new functions handles thinks completely different cause if first char is lowercase and second char is uppercase it does not modfiy it.
> Resulting in a not found setter.
> Is this an intended change so that parameters are no longer allowed to be first letter lowercase, second letter uppercase?
> Greetings Marco C.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)