Allow use of xsl on the fly (output)

[carstenartur]

Prove of concept for using xsl internally to xstream.
Same could be done for input and simplifies usage. Not sure if it would be possible to implement "streaming" (low memory footprint) in some use cases. There are some flaws regarding threading in the implementation but do not care for the moment.

[coveralls]

Coverage increased (+0.006%) to 80.627% when pulling 707ca35 on carstenartur:realmaster into ce95902 on x-stream:master.

[joehni]

Hallo Carsten,

thanks for your contribution, but it seems you did not recognize that XStream has already XSL support? It is wrapped in com.thoughtworks.xstream.io.xml.TraxSource and com.thoughtworks.xstream.io.xml.SaxWriter that turns an XStream instance into a SAX parser used by the transformer. That way the transformer uses directly the events generated by XStream without generating intermediate XML.

However, the implementation did not support an ObjectOutputStream to convert all the stuff on-the-fly. Your implementation gave the idea how to achieve this. Internally I also use a background thread with a simple BlockingQueue. Works like charm.

[carstenartur]

Hi Jörg,
Somehow I overlooked that xstream already has that. Did you implement the input case as well? It nearly looks the same. What is with output of non utf-8 files? Do you have experience with streaming ( using saxon as stylesheet processor)to process big files?
However thanks for pointing out the existing support of xsl..

[joehni]

Hi Carsten,

no, I have no experience in this area. Do you have a use case for the input scenario? Using a style sheet for output makes sense if you generate a completely different format. To use a style sheet as input for XStream simply means you're transforming your XML ... but why? Isn't it possible to configure XStream for the original format in first place?

[carstenartur]

Hi Jörg,
I use it to rewrite different formats generated by different versions of the same software that uses xstream for serialization and does not use its own converters for all data. That way every version of the software can import the older as well as the newer formats. That can be simple things like „enhancing“ using Long instead of Integer or some slightly more complex changes. For that use case it is more important to be able to use xsl on import than on output. The serialization does not look the same in each version but „magically“ can be imported anyway.
You can argue that you should not allow to have elements in the serialization that might be based on classes or attributes that is not available in a newer java version or third party library. However in case you have to live with a legacy format that is a nice trick.

[joehni]

OK, nice approach. I was just interested in a valid use case.

When I have to read different versions of the "same" XML data, I use normally a version attribute in the root element. The converter, that handles it, will put the value in the DataHolder (Context) and the information is therefore available in the complete unmarshaling process ... and so I am able to expect different things depending on the format version.

But yes, this implies more work in converters.

[carstenartur]

One thing to consider: if you use a stylesheet for small changes on import or output changing your code to the traxsource approach seems to be rather heavyweight. Maybe you can think about a second way to make use of a stylesheet similar to the one in this pull request that needs minimal changes to your existing code.