Details
Closed
Major
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
- is duplicated by
-
XSTR-533
An alias for a whole package (and sub packages)
-
Activity
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 
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 Some basic tests that demonstrate this behaviour.
Maarten Winkels
added a comment - Some basic tests that demonstrate this behaviour. 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.
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. I've implemented now an own solution using a separate PackageAliasingMapper. Main reason was the precedence rule for longer package names.
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. Set correct fix version.
Jörg Schaible
added a comment - Set correct fix version. Fixed for upcoming release.
Jörg Schaible
added a comment - Fixed for upcoming release. 
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.