Extensive global synchronizations about jcabi-xml HOT 6 OPEN

@lightoze this is on purpose, because DOM is not thread-safe, but we promise that our classes are thread-safe.

from jcabi-xml.

Let's look at XLSDocument case first. You create local TransformerFactory and Transformer instances, so you should not worry about them. DOM itself is a potential source of a problem (when the same document is used in concurrent transformations), but in this case synchronization should be on xml, xml.node() or whatever.

from jcabi-xml.

The problem is that creating a local instance of Transformer doesn't make it thread safe :( I believe it's full of static properties inside.

from jcabi-xml.

Do you want to say that it's impossible to run two concurrent XSL transformations inside the same JVM?That's ridiculous.
Transformer documentation says clearly: An object of this class may not be used in multiple threads running concurrently. Different Transformers may be used concurrently by different threads.

from jcabi-xml.

Yes, that's exactly what I'm saying and I have a test that proves it. Take a look: https://github.com/jcabi/jcabi-xml/blob/master/src/test/java/com/jcabi/xml/XSLDocumentTest.java#L72-L98

Try to remove synchronization and run mvn clean test and you will see what happens.

from jcabi-xml.

Just did exactly what you suggested - the test is not failing with removed synchronization. Can you reproduce it yourself now?
Tested with JRE 1.8.0_31 and 1.7.0_76

from jcabi-xml.