> Don't treat users as stupid, they are not. I didn't say anything about 'stupid'! AFAIK it's a usability benefit to minimize user mistakes (just think about a developer who in a morning is angry against employer or wife and sees an error about exclusions, he or she simply overrides them I think)
And I remember a user asking at user list that what happens if he removes Object from excluded classes. What we should say? you can but at your risk! > If right now we had it hard-coded then current release would be total fail. > There are valid use cases where excluded classes / packages must be allowed. If I was those users, I was moving those logics into my actions (outside of the excluded packages) instead of removing an exclusion globally. > There are bigger problems at hand if injection fails, probably. :) I remember several issues about not working validations which after a lot investigating were because of silently failed injections. > Current tests will still not reveal this issue. > Problem is in the lack of proper integration tests. Because Lukasz already has moved the XWorkList. If you revert back XWorkList, this PR fails with: ``` 2018-09-03 13:28:45,626 WARN [main] ognl.SecurityMemberAccess (SecurityMemberAccess.java:78) - Package of target [[1, 2, 3]] or package of member [public boolean com.opensymphony.xwork2.util.XWorkList.contains(java.lang.Object)] are excluded! [INFO] [INFO] Results: [INFO] [ERROR] Failures: [ERROR] XWorkListPropertyAccessorTest.testContains:48 NullPointer [INFO] [ERROR] Tests run: 1794, Failures: 1, Errors: 0, Skipped: 0 ``` As you see, if it was hard coded then it was discovering this issue sooner than user :( > Bottom line is: This is not backward compatible and cannot be released in > next 2.5.x series. This is backward compatible but only for users who has overrided these important exclusions which is not bad to meet them, I think :) [ Full content available at: https://github.com/apache/struts/pull/247 ] This message was relayed via gitbox.apache.org for [email protected]
