|
Well, setting repairing mode results in exception in both 3.2.4 and 3.9.0
javax.xml.stream.XMLStreamException: Repairing mode not (yet) supported with DOM-backed writer at com.ctc.wstx.dom.DOMWrappingWriter.<init>(DOMWrappingWriter.java:111) at com.ctc.wstx.dom.DOMWrappingWriter.createFrom(DOMWrappingWriter.java:151) at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:322) at com.ctc.wstx.stax.WstxOutputFactory.createXMLEventWriter(WstxOutputFactory.java:101) at MessageMain.buildCsMessage(MessageMain.java:481) at MessageMain.main(MessageMain.java:129) Really? That is very weird. It was definitely supposed to be enabled in latest versions. I will look into it.
I tested this with 3.2.4 and 3.9.0, and repairing writer can be instantiated. However, since this was not implemented prior to 3.2, woodstox 3.1.2 jar does throw an exception indicating it can't instantiate DOM backed reader. Is it possible you might have an older jar (3.2.2 maybe?).
I also noticed that I have forgotten to indicate work on improved DOM-based stream writer from release notes – although a version was included in 3.2.2, that version did not implement repairing; this is a more recent addition. So, you should be able to enable repairing mode in 3.2.4 and 3.9.0. But it remains to be seen whether that would address the fundamental problem. Let's hope we can address it, once we can further isolate the root cause. Well I'm pretty sure. I captured exact WstxOutputFactory class location with code:
XMLEventWriter writer = outputFactory.createXMLEventWriter(result); and result is: A have given a try to lgpl bundled 3.2.4 and asl 3.9.0 but with same error Very strange. Is there any chance you might have old version(s) lurking somewhere in classpath?
The way I tested this was to write just one class, compile & run with woodstox jar. It's just that this specific part of code was removed before 3.2.4 / 3.9.0 releases from the codebase... so it would seem most logical that somehow you managed to get old version of the class (if multiple conflicting jars are in classpath you won't get an error, just end up with class(es) from somewhat arbitrary jar). Now I am deadly sure, that not any other version interferes. I even tried it on 4 different machines. (WinXP, Win2003, debian, HP-UX) with different versions of 1.5 jdk an result is allways same. But beware, it works on 1.6 because jdk internal stax implementation is chosen!
T:\stax>C:\sis\jdk1.5.0_10\bin\java.exe -cp .;wstx-asl-3.9.0.jar;stax-api-1.0.1.jar StaxWirdo javax.xml.stream.XMLStreamException: Repairing mode not (yet) supported with DOM-backed writer at com.ctc.wstx.dom.DOMWrappingWriter.<init>(DOMWrappingWriter.java:111) at com.ctc.wstx.dom.DOMWrappingWriter.createFrom(DOMWrappingWriter.java:151) at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:322) at com.ctc.wstx.stax.WstxOutputFactory.createXMLEventWriter(WstxOutputFactory.java:101) at StaxWirdo.main(StaxWirdo.java:35) T:\stax>C:\sis\jdk1.5.0_10\bin\java.exe -cp .;wstx-asl-3.2.4.jar;stax-api-1.0.1.jar StaxWirdo I think I found the problem, finally. While the fix (to
So, this will be resolved when I cut the first 4.0(pr1) version. I plan to do this soon now. Woodstox 3.9.1 release contains support for DOM-backed writer with namespace-repairing mode.
Martin, since there have been many changes to DOMWrappingWriter class (some of which hopefully address the problem), is there any chance you could try to reproduce the problem with it? (preferably first without enabling namespace repairing mode).
Ack. Never mind – I think I found the actual bug. It's due to failure to pass prefix when writing namespace.
I will fix this particular problem in trunk (for 3.9.3), may backport to 3.2 branch (for 3.2.6). Check is fixed in trunk now, anyway, and there is a DOM unit test to catch the problem. Martin, would you be able to check if code from trunk or 3.2 branch works for you now? (I did backport patch from trunk to 3.2 branch)
I think I fixed the problem you have, and am planning to make 3.2.6 release. So it would be great if I could confirm that this problem has indeed been resolved. Without submitter verification I can't be 100% positive about this, but I am fairly confident that this problem was resolved for 3.2.6 release.
Assuming problem was resolved (there are further DOM-related fixes in 3.2.7 release as well): reopen if there are remaining related issues.
|
|||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Failed marshalling to from JAXB to DOM through XMLStreamWriter or XMLEventWriter
It is bit difficult to troubleshoot this problem without knowing more about call sequences, but perhaps same problem would occur with non-repairing stream writer too.
One work-around you could also try is to set repairing mode on in the output factory, to see if that would resolve the problem.