Spring Framework fails to find bean property if the setter contains more than one capital after the word set (e.g., setTEmailAddr) [SPR-7388]

[spring-projects-issues]

Paul DesRivieres opened SPR-7388 and commented

If you use the Spring Framework to automatically bind parameters in your HttpServletRequest to your request context object, please be aware of this Spring bug confirmed in version 2.0 and 2.5.6.

If you have setters setF, setTg, and setDevId in your request context class, Spring will detect properties 'f', 'tg', and 'devId' bind those parameters to your setters.
However, if you have setters setTBrandi, setTBid, setTEmailAddr, and setTLoginNumber, Spring will detect properties 'TBrandi', 'TBid', 'TEmailAddr', and 'TLoginNumber' rather than 'tBrandi', 'tBid', 'tEmailAddr', and 'tLoginNumber'.
For these parameters you would need to manually call the setters or they won't be defined in your request context.

It seems the bug occurs when your setter has more than one capital letter in a row immediately after the set as setTg and setDevId work but not setTBid and setTEmailAddr.

Renaming the setter from setTEmailAddr to settEmailAddr does resolve the issue.
2010-07-20 15:11:05,498 [http-9080-1] DEBUG org.springframework.beans.CachedIntrospectionResults - Found bean property 'tEmailAddr' of type [java.lang.String]
...
2010-07-20 15:11:05,502 [http-9080-1] DEBUG org.springframework.beans.BeanWrapperImpl - Invoked write method [public void com.aol.mail.services.mps.common.ServiceRequest.settEmailAddr(java.lang.String)] with value of type [java.lang.String]

Paul D.

---

Affects: 2.5.6

Issue Links:

• Lenient property name casing (beyond standard JavaBeans conventions) [SPR-6491] #11157 Lenient property name casing (beyond standard JavaBeans conventions)

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is not a bug but actually correct behavior according to the JavaBeans specification: Check the javadoc of java.beans.Introspector's "decapitalize" method to find a summary of the (not well known) rules there.

Spring 2.x was still strictly JavaBeans compliant. As of Spring 3.0, we adopted a more lenient strategy that goes beyond the JavaBeans spec: We accept both variants of such casing now (i.e. "TBid" as well as "tBid").

Juergen