-
Bug
-
Resolution: Fixed
-
Major
TreeUnmarshaller in XStream has a bug that it pushes a class onto a types stack but fails to pop it in a finally block. Then if there is an error, the context's requiredType will be bogus, which can confuse DescribableList.ConverterImpl.unmarshal as it tries to pick the right kind of list to create—it will find the type of one of the list's elements. You will end up with a ClassCastException if that type has a public no-arg constructor, or a NoSuchMethodException if it does not. The XStream bug is aggravated by the order in which the Jenkins code calls things.
Not to be confused with JENKINS-27736, which is quite different.
- relates to
-
JENKINS-49169 Investigate XStream stack unwinding behavior esp. in TreeUnmarshaller
-
- Open
-
- links to
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/java/hudson/util/DescribableList.java
core/src/test/java/hudson/util/DescribableListTest.java
http://jenkins-ci.org/commit/jenkins/976fe5aaa05858b88c5141b8d133efea696233b8
Log:
JENKINS-49054Work around XStream bug by looking up list type before trying to unmarshal elements.