Extend creation of XStream [SWS-34]

[gregturn]

Francesc Xavier Magdaleno opened SWS-34 and commented

Hey,

I am currently using your framework, but have notice in the class org.springframework.oxm.xstream.XStreamMarshaller the creation of com.thoughtworks.xstream.XStream can not be injected. In some cases could be funny to perform a customization of this object (probably when you are working with attributes or when you would like tio modify the driver)
and the introduction of a setXStream(XStream xstream) could help us!! nevertheless, congratulations for your work!!

thanks a lot!!!

Francesc Xavier

---

Affects: 1.0 M1

Attachments:

• xstream-with-attributes.rar (23.48 kB)

[gregturn]

Arjen Poutsma commented

I'd rather add the attributes to the XStreamMarshaller itself (delegating to the private XStream instance), because that is the approach taken for the rest of the marshallers (for instance the setValidating on the Jaxb1Marshaller, and setSchema on Jaxb2Marshaller). If you set the XStream instance directly, the whole idea of the Marshaller/Unmarshaller abstraction goes away. So which attributes of XStream do you want to change? I see if I can add them to the marshaller.

If, however, this approach is impossible, I can expose the Xstream instance.

Thanks for the support!

[gregturn]

Francesc Xavier Magdaleno commented

Hey!!

well, xstream works well when your xml has not attributes in your elements (as far as known, in fact i am not an expert in xstream) but if you want to support this feature you have to add another library available here http://xstream.plpgroup.org/xstream-attributes-src.zip (if does not work i can send you), which customizes the creation of your XStream instance (including specify your com.thoughtworks.xstream.io.HierarchicalStreamDriver). Well, it is just supporting the injection of com.thoughtworks.xstream.XStream (in a method setXStream(XStream xstream))in the org.springframework.oxm.xstream.XStreamMarshaller, therefore offerting a way to customize the creation of this object when you describe this bean in your Spring application contexts!!

thanks a lot!!!!

[gregturn]

Arjen Poutsma commented

The xstream-attributes zip is not longer available. Could you maybe attach it to this issue? Then I will try and incorporate it.

Thanks

[gregturn]

Francesc Xavier Magdaleno commented

Hey,

i did not known that the link that's not work!!!
i hope it will be useful!!! it is only to allow custom xstrem building with xml's with has attributes. Probably ina new release of XStream will include this functionality

[gregturn]

Francesc Xavier Magdaleno commented

Hey,

I have attached a rar with the source and distribution of the library wich extends functionality of XStream with attributes i hope it will be useful

thanks a lot!!

[gregturn]

Arjen Poutsma commented

I've added a way to register custom Converters to the XStream instance. That should allow you to register the AttributesConverter contained in the jar appended to this issue.

If the XStreamFactory contained in the jar ever makes it to the main distribution of XStream, we can start to use that. Until that time, I prefer not to depend on it.

Once again, I chose not to expose the internal XStream instance, because that would really break the contract, and I don't think it's necessary. If you absolutely need to have it, I could still add a setXStream() method to the marshaller.

[gregturn]

Ronald Tetsuo Miura commented

I think the common contract (not only XStream's, but others) should be to expose the underlying API, because it would not require changes to the marshaller API if the other libraries changes, even if binary compatibility is maintained.

By exposing the underlying API, one could immediately use new features of new versions of those APIs, instead of waiting for an Spring-WS update.