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

RobustReflectionConverter is not used in some cases

    • Icon: Improvement Improvement
    • Resolution: Done
    • Icon: Minor Minor
    • core
    • None

      There are a few cases where XStream internally passes its default instance of ReflectionConverter to other converter instances. When these converters drill down into their fields, they do not use RobustReflectionConverter and the overall conversion becomes subject to the same failures that RobustReflectionConverter was created to avoid. Here is a list of converters that are passed the default ReflectionConverter in XStream 1.3.1:

      ThrowableConverter
      RegexPatternConverter
      SerializableConverter
      LookAndFeelConverter
      SelfStreamingInstanceChecker

      In our case, the fact that the ThrowableConverter was not calling RobustReflectionConvert combined with an error in class member munging described in JENKINS-5768 to cause our build.xml deserializable to fail, cause the build in question to not be loaded into memory on startup.

          [JENKINS-5769] RobustReflectionConverter is not used in some cases

          mdillon created issue -

          mdillon added a comment -

          For what it's worth, I was able to work around this issue for the ThrowableConverter case by putting the following code into a plugin:

          static {
              fixConverters(hudson.model.Hudson.XSTREAM);
              fixConverters(hudson.model.Items.XSTREAM);
              fixConverters(hudson.model.Run.XSTREAM);
          }
          
          private static void fixConverters(XStream xs) {
              Converter converter = xs.getConverterLookup().lookupConverterForType(Object.class);
              if (converter instanceof RobustReflectionConverter) {
                  xs.registerConverter(new ThrowableConverter(converter), 10);
              }
          }
          

          mdillon added a comment - For what it's worth, I was able to work around this issue for the ThrowableConverter case by putting the following code into a plugin: static { fixConverters(hudson.model.Hudson.XSTREAM); fixConverters(hudson.model.Items.XSTREAM); fixConverters(hudson.model.Run.XSTREAM); } private static void fixConverters(XStream xs) { Converter converter = xs.getConverterLookup().lookupConverterForType( Object .class); if (converter instanceof RobustReflectionConverter) { xs.registerConverter( new ThrowableConverter(converter), 10); } }

          mdillon added a comment -

          I looked at this a little closer and the only converters that have a direct reference to the original ReflectionConverter are ThrowableConverter, RegexPatternConverter, and SelfStreamingInstanceChecker. The other ones I mention take the "reflectionProvider" in the constructor, not the "reflectionConverter".

          mdillon added a comment - I looked at this a little closer and the only converters that have a direct reference to the original ReflectionConverter are ThrowableConverter, RegexPatternConverter, and SelfStreamingInstanceChecker. The other ones I mention take the "reflectionProvider" in the constructor, not the "reflectionConverter".

          mdillon added a comment -

          This patch changes XStream2 to "replace" ThrowableConverter, RegexPatternConverter, and SelfStreamingInstanceChecker with ones that delegate to RobustReflectionConverter.

          The only one I've seen fail is ThrowableConverter. Failure of RegexPatternConverter seems unlikely since Pattern is not generally subclasses. I'm not sure what SelfStreamingInstanceChecker actually does, so I can't say whether or not the likelihood of a failure in the default ReflectionConverter is likely to bubble up and cause it to have an exception itself.

          mdillon added a comment - This patch changes XStream2 to "replace" ThrowableConverter, RegexPatternConverter, and SelfStreamingInstanceChecker with ones that delegate to RobustReflectionConverter. The only one I've seen fail is ThrowableConverter. Failure of RegexPatternConverter seems unlikely since Pattern is not generally subclasses. I'm not sure what SelfStreamingInstanceChecker actually does, so I can't say whether or not the likelihood of a failure in the default ReflectionConverter is likely to bubble up and cause it to have an exception itself.
          mdillon made changes -
          Attachment New: XStream2.java.diff [ 19190 ]

          mdillon added a comment -

          One more note. It seems like the right fix for this might be in XStream. It seems like they should be using the convertAnother method on the MarshallingContext/UnmarshallingContext, but those method can't be passed a HierarchicalStreamWriter or HierarchicalStreamReader. Not sure if the contexts have enough information for that not to matter.

          mdillon added a comment - One more note. It seems like the right fix for this might be in XStream. It seems like they should be using the convertAnother method on the MarshallingContext/UnmarshallingContext, but those method can't be passed a HierarchicalStreamWriter or HierarchicalStreamReader. Not sure if the contexts have enough information for that not to matter.
          Alan Harder made changes -
          Assignee New: Alan Harder [ mindless ]

          Alan Harder added a comment -

          I don't think convertAnother can be used, as it will just come back to ThrowableConverter, creating an infinite loop.. know a way around this?

          Alan Harder added a comment - I don't think convertAnother can be used, as it will just come back to ThrowableConverter, creating an infinite loop.. know a way around this?

          mdillon added a comment -

          That must be why they maintain the direct reference to the default converter. You're right that using convertAnother would not be workable. An alternative change for XStream that might be helpful would be for them to add a "protected Converter createReflectionConverter()" on the XStream class. That would let XStream2 replace the default reflection converter with RobustReflectionConverter.

          Putting aside the discussion of what could be changed in XStream itself, does my patch for Hudson seem workable? Aside from the nastiness of having to know the priority associated with the original converters and the lack of the ability to simply replace those converters directly, it seems like a workable approach to me.

          mdillon added a comment - That must be why they maintain the direct reference to the default converter. You're right that using convertAnother would not be workable. An alternative change for XStream that might be helpful would be for them to add a "protected Converter createReflectionConverter()" on the XStream class. That would let XStream2 replace the default reflection converter with RobustReflectionConverter. Putting aside the discussion of what could be changed in XStream itself, does my patch for Hudson seem workable? Aside from the nastiness of having to know the priority associated with the original converters and the lack of the ability to simply replace those converters directly, it seems like a workable approach to me.

          Alan Harder added a comment -

          Yes, both solutions are workable.. we already have a forked XStream, and I'm on the fence about whether to add another custom change in there. But I do like that createReflectionConverter (or maybe createDefaultConverter) idea, as it would make the full registry of converters a bit cleaner.. "replacing" ThrowableConverter, etc. actually leaves the original instances in the registry, though I guess they'd never be used.
          Pattern is a final class, so I'd expect RegexPatternConverter to always work.. SelfStreamingInstanceChecker is for serializing XStream[2] objects which I doubt we'd ever do.. so really only ThrowableConverter matters here, though I guess we can replace them all just for completeness (or modify XStream as you suggested and then they'll all have the right default converter anyway).

          Alan Harder added a comment - Yes, both solutions are workable.. we already have a forked XStream, and I'm on the fence about whether to add another custom change in there. But I do like that createReflectionConverter (or maybe createDefaultConverter) idea, as it would make the full registry of converters a bit cleaner.. "replacing" ThrowableConverter, etc. actually leaves the original instances in the registry, though I guess they'd never be used. Pattern is a final class, so I'd expect RegexPatternConverter to always work.. SelfStreamingInstanceChecker is for serializing XStream [2] objects which I doubt we'd ever do.. so really only ThrowableConverter matters here, though I guess we can replace them all just for completeness (or modify XStream as you suggested and then they'll all have the right default converter anyway).

            mindless Alan Harder
            md5 Mike Dillon
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: