-
Bug
-
Resolution: Fixed
-
Minor
https://github.com/jenkinsci/jenkins/pull/3122 changed the AbstractTaskListener in a non serialization friendly way.
For Jenkins this is not normally a problem as the same versions of classes will be used on both ends of a remoting endpoint, but custom derivatives may not have this luxury, or may use a different form of serialization other than XStream.
The simple fix that appears to work is to restore the serialVersionUID to the pre change version.
- relates to
-
JENKINS-48116 Jenkins 2.91 breaks builds which require Ruby
-
- Resolved
-
- links to
[JENKINS-50124] restore class compatibility for AbstractTaskListener
Remote Link | New: This issue links to "PR (Web Link)" [ 20253 ] |
Labels | New: lts-candidate |
Summary | Original: restore class compatability for AbstractTaskListner | New: restore class compatibility for AbstractTaskListner |
Summary | Original: restore class compatibility for AbstractTaskListner | New: restore class compatibility for AbstractTaskListener |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Code changed in jenkins
User: James Nord
Path:
core/src/main/java/hudson/util/AbstractTaskListener.java
http://jenkins-ci.org/commit/jenkins/dcf22ca809671f19cfc2d1d10537b7bb5cf56e8d
Log:
JENKINS-50124restore AbstractTaskListeners serialVersionUID.If a subclass was serialized (default java serialization) then the
changes do push down the method to the interface would break
deserialisation when in reality the classes are still compatable.
Restoring the compatability by hard coding the serialVersionUID to what
it was before the change.