Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Incomplete
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Compatibility, Converters, Core
-
Labels:None
Description
We use XStream for XML marshallin on our project (HudsonCI) for a long time.
Based on our experience on XStream usage we sometimes faced with situations, where XStream functionality needs extending. But basically, we can't do it without patching sources. So, we propose several patches which will really help to resolve this situation and use the latest available version of XStream
Please, let me know, if you agree to apply them.
There 4 patches:
1. Introduce NonExistentFieldException
2. Expose XStream.JVM and XStream.ConverterRegistry properties
3. Improve EnumConverter
4. Add ability to override PureJavaReflectionProvider
5. Add 2 new annotations
Thanks for your help.
P.S. if you can propose some API or workarounds for our patches, it would be great.
Issue Links
Activity
Hi Nikita,
I had a look over the patches now. Since you already requested it, I will first provide some solutions working with the current XStream release and wait on your comments again.
- Custom ReflectionProvider: The normal use case to provide an alternative ReflectionProvider is the constructor of the XStream. Therefore I do not see why you really need to expose the JVM instance and overload its bestReflectionProvider method, since this is only used as fallback, if no such ReflectionProvider instance is given to initialize the XStream.
- The ConverterRegistry was not exposed on purpose, you should use XStream.registerConverter for later access. You may nevertheless provide an own instance again as parameter for the XStream constructor.
- EnumConverter enhancement: You can simply register your own version of the EnumConverter, it will take precedence over XStream's internal one.
- XStreamSerializable: I see no need to add such an annotation, since it is used in a custom ReflectionProvider which can be provided in XStream's constructor.
- XStreamSeializableAs: It looks like this reflects the functionality of XStream.aliasType. The reason to provide no annotation for this functionality is, that you may often not be able to declare it at the super type, since it is provided by 3rd party or the JDK directly.
- NotExistentFieldException: This is actually a good possibility to distinct the case of failing access because the field does not exist. There are more places in the code base where this exception has to be thrown, but I can easily identify them.
- Jörg
Jörg Schaible
added a comment - Hi Nikita,
I had a look over the patches now. Since you already requested it, I will first provide some solutions working with the current XStream release and wait on your comments again.
Custom ReflectionProvider: The normal use case to provide an alternative ReflectionProvider is the constructor of the XStream. Therefore I do not see why you really need to expose the JVM instance and overload its bestReflectionProvider method, since this is only used as fallback, if no such ReflectionProvider instance is given to initialize the XStream.
The ConverterRegistry was not exposed on purpose, you should use XStream.registerConverter for later access. You may nevertheless provide an own instance again as parameter for the XStream constructor.
EnumConverter enhancement: You can simply register your own version of the EnumConverter, it will take precedence over XStream's internal one.
XStreamSerializable: I see no need to add such an annotation, since it is used in a custom ReflectionProvider which can be provided in XStream's constructor.
XStreamSeializableAs: It looks like this reflects the functionality of XStream.aliasType. The reason to provide no annotation for this functionality is, that you may often not be able to declare it at the super type, since it is provided by 3rd party or the JDK directly.
NotExistentFieldException: This is actually a good possibility to distinct the case of failing access because the field does not exist. There are more places in the code base where this exception has to be thrown, but I can easily identify them.
Jörg
Hello ,
Thank you for replay. I want to propose additional patch, that help to peekNextChild during unmarshalling process.
It would be great, if you could apply it to XSTREAM release
Thank you
P.S. as for my previous comment #6: are you going to include this patch to future releases? If yes, what version will it be?
Nikita Levyankov
added a comment - - edited Hello ,
Thank you for replay. I want to propose additional patch, that help to peekNextChild during unmarshalling process.
It would be great, if you could apply it to XSTREAM release
Thank you
P.S. as for my previous comment #6: are you going to include this patch to future releases? If yes, what version will it be? I've applied MissingFieldException to trunk and identified some more places where this should be used instead. I'll have to review the latest patch still. BTW: It would help now to have separate issues in JIRA.
Jörg Schaible
added a comment - I've applied MissingFieldException to trunk and identified some more places where this should be used instead. I'll have to review the latest patch still. BTW: It would help now to have separate issues in JIRA. Nikita Levyankov
added a comment - I have introduced separate issues.
1. XSTR-675
2. XSTR-676
This issue could be closed for now Closed on request. Added links to separate issues which supercede the current one.
Jörg Schaible
added a comment - Closed on request. Added links to separate issues which supercede the current one. 
Is there any progress on this issue?