XStream
  1. XStream
  2. XSTR-55

Ability to alias an entire package

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.3.1
    • Component/s: Core
    • Labels:
      None

      Description

      Rather than having to do:

      xstream.alias("com.blah.mypackage.MyClass", "MyClass");
      xstream.alias("com.blah.mypackage.YourClass", "YourClass");
      xstream.alias("com.blah.mypackage.SheepClass", "SheepClass");

      I'd like to be able to do:

      xstream.aliasPackage("com.blah.mypackage");

        Issue Links

          Activity

          Hide
          Grégory Joseph (old account) added a comment -

          Here's a very basic patch that allows this.
          I've factored out two methods in DefaultClassMapper and made the loadClass method of DefaultClassMapper protected; this PackageAliasClassMapper simply extends DefaultClassMapper.
          Please review and tell me what you think.

          Show
          Grégory Joseph (old account) added a comment - Here's a very basic patch that allows this. I've factored out two methods in DefaultClassMapper and made the loadClass method of DefaultClassMapper protected; this PackageAliasClassMapper simply extends DefaultClassMapper. Please review and tell me what you think.
          Hide
          Grégory Joseph (old account) added a comment -

          The previous patch isn't really satisfying me, because :

          • it doesn't actually map a package name to a "shortcut" name, but to empty string (ie, com.blah.bleh.SomeClass can not be aliased to "foo.SomeClass" but only to SomeClass)
          • it's based on startsWith and substring methods, which makes it a bit hairy - and possibly not very safe - for the sake of aliasing com.blah.bleh.bluh.SomeOtherClass to "bluh.SomeOtherClass"

          I'm planning on submitting another patch that would

          • allow actual aliasing of a package to a "prefix", but only A package and not it's subpackages
          • be based on full package name of a Class instead of just using startsWith on Class.getName()

          ... I'll do that .. eventually.. when my pc resurects.

          Please tell me what you think, anyway

          Show
          Grégory Joseph (old account) added a comment - The previous patch isn't really satisfying me, because : it doesn't actually map a package name to a "shortcut" name, but to empty string (ie, com.blah.bleh.SomeClass can not be aliased to "foo.SomeClass" but only to SomeClass) it's based on startsWith and substring methods, which makes it a bit hairy - and possibly not very safe - for the sake of aliasing com.blah.bleh.bluh.SomeOtherClass to "bluh.SomeOtherClass" I'm planning on submitting another patch that would allow actual aliasing of a package to a "prefix", but only A package and not it's subpackages be based on full package name of a Class instead of just using startsWith on Class.getName() ... I'll do that .. eventually.. when my pc resurects. Please tell me what you think, anyway
          Hide
          Maarten Winkels added a comment -

          Some basic tests that demonstrate this behaviour.

          Show
          Maarten Winkels added a comment - Some basic tests that demonstrate this behaviour.
          Hide
          Maarten Winkels added a comment -

          This patch (see attachment) allows for multiple "default packages" to be specified. The classes in these packages will be mapped by their "short class name" (as by ClassUtils.shortClassName(type)). When an alias for a "default package"-class is found it is stored as a simple alias for fast future access.

          Show
          Maarten Winkels added a comment - This patch (see attachment) allows for multiple "default packages" to be specified. The classes in these packages will be mapped by their "short class name" (as by ClassUtils.shortClassName(type)). When an alias for a "default package"-class is found it is stored as a simple alias for fast future access.
          Hide
          Jörg Schaible added a comment -

          I've implemented now an own solution using a separate PackageAliasingMapper. Main reason was the precedence rule for longer package names.

          Show
          Jörg Schaible added a comment - I've implemented now an own solution using a separate PackageAliasingMapper. Main reason was the precedence rule for longer package names.
          Hide
          Jörg Schaible added a comment -

          Set correct fix version.

          Show
          Jörg Schaible added a comment - Set correct fix version.
          Hide
          Jörg Schaible added a comment -

          Fixed for upcoming release.

          Show
          Jörg Schaible added a comment - Fixed for upcoming release.

            People

            • Assignee:
              Jörg Schaible
              Reporter:
              Joe Walnes
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: