Details
-
Type:
Improvement
-
Status:
Closed
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
I have written a custom Converter which decides based on the document element's version how the document should be parsed. A certain version is parsed by registering a number of other custom converters and some aliases. However, It also needs to unregister converters or remove an alias in certain situations. As there is no api for this yet, and a number of fields in the DefaultConverterLookup and DefaultClassMapper classes are set to private, I basically need to copy those classes completetly, althoug I would only need to modify a few lines.
It would be good if there was an unregisterConverter and unregisterAlias method in the XStream/DefaultConverterLookup/DefaultClassMapper class or at least the private fields were set to protected.
Activity
Patch with just one method for unregistering a converter
Remember to implement your own equals method otherwise the default equals method will be called.
We could also develop some unregisterMethod which removes the converter with ANY priority.
This patch also deals with cache problems.
Guilherme Silveira
added a comment - Patch with just one method for unregistering a converter
Remember to implement your own equals method otherwise the default equals method will be called.
We could also develop some unregisterMethod which removes the converter with ANY priority.
This patch also deals with cache problems. The primary description of this issue implies the modification of the setup of an XStream instance at (un)marshalling time. This is highly discouraged and not really supported, because XStream uses internal caches, that will not be flushed, if something is changed, and because it is on top not thread-safe at all.
XStream's default mechanism for converters is to override them either with equal or higher priority (the NullConverter is registered as VERY_HIGH). Remember, that a converter provides no information, which types it actually handles therefore it does not make sense to unregister a converter for type X. Nevertheless, you can provide an own implementation of a ConverterRegistry that supports unregistration - you just cannot use the XStream facade.
To support multiple versions of an XML structure, you might transport the version info in the context and use converters that can act on the provided version.
Jörg Schaible
added a comment - The primary description of this issue implies the modification of the setup of an XStream instance at (un)marshalling time. This is highly discouraged and not really supported, because XStream uses internal caches, that will not be flushed, if something is changed, and because it is on top not thread-safe at all.
XStream's default mechanism for converters is to override them either with equal or higher priority (the NullConverter is registered as VERY_HIGH). Remember, that a converter provides no information, which types it actually handles therefore it does not make sense to unregister a converter for type X. Nevertheless, you can provide an own implementation of a ConverterRegistry that supports unregistration - you just cannot use the XStream facade.
To support multiple versions of an XML structure, you might transport the version info in the context and use converters that can act on the provided version. 
Adding my own NullConverter , i need to remove the custom converter programaticly.
Regards Rickard Lundin (sweden 2005-06-29)