1. XStream
  2. XSTR-670

Mappers should be given more context to resolve a class


    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4.1
    • Fix Version/s: None
    • Component/s: Converters, Core
    • Labels:


      We are using XStream in Bamboo to serialize stuff into database as well as over the JMS wire. Bamboo is running an OSGi-based plugin system and recently we made the build agents run the plugin system as well and that brought about some problems, one of them being able to serialize/deserialize classes coming from plugins (OSGi bundles).

      After having an extended play with XStream to see the possible solutions we came up with some workarounds, but we feel that XStream API might be improved in this regard. More specifically, it seems that the component responsible for loading the classes is Mapper. Unfortunately mapper is just arbitrarily given an element's name/class attribute. In our case we would like to encode plugin key (equivalent to OSGi bundle symbolic name) and version, so that on the other side we can find corresponding plugin/bundle, make sure it exists and has corresponding version, and use it to load the class. It seems like there could be e.g. an ExtendedMapper interface that would have 'extended' version of methods responsible for serializing/loading classes (like realClass(String name) that would be given more context, in particular the HierarchicalStreamrReader/HierarchicalStreamWriter instance (or sub-interface of it) to read/write attributes. It could then be used in HierarchicalStreams et al. to read/write 'extended' information about the class.

      An example of what I have in mind:

      // marshalling
      if (mapper instanceof ExtendedMapper) {
      } else {
         // the 'normal' way
         writer.addAttribute("class", mapper().serializedClass(object.getClass()));
      // unmarshalling (in HierarchicalStreams.readClassType()?)
      if (mapper instanceof ExtendedMapper) {
         return ExtendedMapper.class.cast(mapper).realClass(reader);
      } else {
         // the old way - check class attribute/element name

      We tried various workarounds, one that we will probably settle down with is to encode all the information (plugin key, plugin version) in the class name - but it still sounds like a workaround, not a robust solution...


        • Assignee:
          Jörg Schaible
          Dariusz Kordonski
        • Votes:
          0 Vote for this issue
          0 Start watching this issue


          • Created: