Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-66955

Add XStream2 constructor matching super class

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Similar Issues:
    • Released As:
      2.318

      Description

      Jenkins core uses an extension of the the stock `XStream` class from `xstream` library, that's `Xstream2`. The normal usage in plugins that need to somehow interact with XStream is to use one of the corresponding singletons (Items.XSTREAM or Run.XSTREAM mainly).

      However that's limiting more elaborated usages, because any mutation done to those objects are affecting the entire Jenkins instance, for example, registering a special `ConverterLookup` or `ConverterRegistry`. In order to do that without polluting existing singletons new instances need to be created, but a more powerful `XStream2` constructor is needed matching the superclass one:

      `public XStream(ReflectionProvider reflectionProvider, HierarchicalStreamDriver driver, ClassLoaderReference classLoaderReference, Mapper mapper, ConverterLookup converterLookup, ConverterRegistry converterRegistry)`

      Note: this was not needed before because most of the time `XStream` was just working fine, but since the last update (to `xstream:1.4.18`) the built-in `XStream` security is not suitable for usage inside Jenkins as it will reject most of the classes that are deserialized, so `XStream2` is needed.

      Note2: there is no public usage if this new constructor, for now it is only used in a non-public plugin maintained by CloudBees. The need behind the new constructor is to inject `ConverterLookup` and `ConverterRegistry` (as noted before) to be able to pre-process items and builds XML files when transferring them from one Jenkins instance to another using the Move/Copy/Promote feature.

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck Daniel Beck added a comment -

            James Nord Please see https://www.jenkins.io/download/lts/#backporting-process for backporting eligibility. Issue type was wrong.

            Show
            danielbeck Daniel Beck added a comment - James Nord Please see https://www.jenkins.io/download/lts/#backporting-process for backporting eligibility. Issue type was wrong.
            Hide
            amuniz Antonio Muñiz added a comment - - edited

            IMO this is fixing a bug, introduced by the xstream bump (as in the bump caused client code to fail, exotic usages of XStream, yes, but allowed still).

            Before `xstream:1.4.18` client code didn't need to deal with security (as explained in the description), after the xstream version bump client code needs to be adapted, and that requires the new constructor.

            Show
            amuniz Antonio Muñiz added a comment - - edited IMO this is fixing a bug, introduced by the xstream bump (as in the bump caused client code to fail, exotic usages of XStream, yes, but allowed still). Before `xstream:1.4.18` client code didn't need to deal with security (as explained in the description), after the xstream version bump client code needs to be adapted, and that requires the new constructor.
            Hide
            danielbeck Daniel Beck added a comment -

            Already in 2.318, so with 2.319 being the baseline, no need to backport.

            Show
            danielbeck Daniel Beck added a comment - Already in 2.318, so with 2.319 being the baseline, no need to backport.

              People

              Assignee:
              amuniz Antonio Muñiz
              Reporter:
              amuniz Antonio Muñiz
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: