Woodstox

Failed marshalling to from JAXB to DOM through XMLStreamWriter or XMLEventWriter

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    woodstox-3.2.4 and 3.9.0 with xerces-2.8.1 or oracle xml v2 parser
  • Number of attachments :
    1

Description

Everything works fine when using sjsxp 1.0.1 parser, but with woodstox...

Marshalling to DOM Node directly works:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();
Document nsDom = builder.newDocument();
marshaller.marshal(csJaxb, nsDom);

Marshalling through writer fail in both xerces and oracle parser:
DOMResult result = new DOMResult(nsDom);
XMLEventWriter writer = XMLOutputFactory.newInstance().createXMLEventWriter(result);
// XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(result);
marshaller.marshal(csJaxb, writer);

I'm using EventWriter version because we do xml schema validation and another EventWriter is chained to track XPath of validation errors.

xerces stack trace:
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
at org.apache.xerces.dom.AttrNSImpl.<init>(Unknown Source)
at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
at com.ctc.wstx.dom.DOMWrappingWriter.outputAttribute(DOMWrappingWriter.java:537)
at com.ctc.wstx.dom.DOMWrappingWriter.writeNamespace(DOMWrappingWriter.java:300)
at com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.beginStartTag(XMLStreamWriterOutput.java:124)
at com.sun.xml.bind.v2.runtime.output.XmlOutputAbstractImpl.beginStartTag(XmlOutputAbstractImpl.java:98)
at com.sun.xml.bind.v2.runtime.output.NamespaceContextImpl$Element.startElement(NamespaceContextImpl.java:483)
at com.sun.xml.bind.v2.runtime.XMLSerializer.endNamespaceDecls(XMLSerializer.java:283)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:586)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:312)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:490)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:175)

oracle stack trace
oracle.xml.parser.v2.XMLDOMException: invalid namespace http://www.europa.eu/schengen/sis/xsd/v1/csmessages for prefix xmlns
at oracle.xml.parser.v2.XMLElement.setAttributeNS(XMLElement.java:1015)
at com.ctc.wstx.dom.DOMWrappingWriter.outputAttribute(DOMWrappingWriter.java:537)
at com.ctc.wstx.dom.DOMWrappingWriter.writeNamespace(DOMWrappingWriter.java:300)
at com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.beginStartTag(XMLStreamWriterOutput.java:124)
at com.sun.xml.bind.v2.runtime.output.XmlOutputAbstractImpl.beginStartTag(XmlOutputAbstractImpl.java:98)
at com.sun.xml.bind.v2.runtime.output.NamespaceContextImpl$Element.startElement(NamespaceContextImpl.java:483)
at com.sun.xml.bind.v2.runtime.XMLSerializer.endNamespaceDecls(XMLSerializer.java:283)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:586)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:312)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:490)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:175)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Quick question: would it be possible to try and see what xml would straight xml event writer (to a file) produce, with otherwise similar setup. That is, instead of DOMResult, use a stream result?
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.

Show
Tatu Saloranta added a comment - Quick question: would it be possible to try and see what xml would straight xml event writer (to a file) produce, with otherwise similar setup. That is, instead of DOMResult, use a stream result? 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.
Hide
Permalink
Martin Vanek added a comment -

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)

Show
Martin Vanek added a comment - 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)
Hide
Permalink
Tatu Saloranta added a comment -

Really? That is very weird. It was definitely supposed to be enabled in latest versions. I will look into it.

Show
Tatu Saloranta added a comment - Really? That is very weird. It was definitely supposed to be enabled in latest versions. I will look into it.
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.
Hide
Permalink
Martin Vanek added a comment -

Well I'm pretty sure. I captured exact WstxOutputFactory class location with code:

XMLEventWriter writer = outputFactory.createXMLEventWriter(result);
String res = writer.getClass().getName().replace(".", "/") + ".class";
URL url = Thread.currentThread().getContextClassLoader().getResource(res);
System.out.println(url);

and result is:
jar:file:/C:/Documents%20and%20Settings/vanek/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.4/wstx-asl-3.2.4.jar!/com/ctc/wstx/evt/WstxEventWriter.class

A have given a try to lgpl bundled 3.2.4 and asl 3.9.0 but with same error
jar:file:/C:/Documents%20and%20Settings/vanek/.m2/repository/org/codehaus/woodstox/wstx-asl/3.9.0/wstx-asl-3.9.0.jar!/org/codehaus/stax2/ri/Stax2EventWriterImpl.class
BTW, as can be seen I'm pulling jars from maven2 repository, but I even manually downloaded woodstox and used in classpath with same result.
I'm not getting it

Show
Martin Vanek added a comment - Well I'm pretty sure. I captured exact WstxOutputFactory class location with code: XMLEventWriter writer = outputFactory.createXMLEventWriter(result); String res = writer.getClass().getName().replace(".", "/") + ".class"; URL url = Thread.currentThread().getContextClassLoader().getResource(res); System.out.println(url); and result is: jar:file:/C:/Documents%20and%20Settings/vanek/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.4/wstx-asl-3.2.4.jar!/com/ctc/wstx/evt/WstxEventWriter.class A have given a try to lgpl bundled 3.2.4 and asl 3.9.0 but with same error jar:file:/C:/Documents%20and%20Settings/vanek/.m2/repository/org/codehaus/woodstox/wstx-asl/3.9.0/wstx-asl-3.9.0.jar!/org/codehaus/stax2/ri/Stax2EventWriterImpl.class BTW, as can be seen I'm pulling jars from maven2 repository, but I even manually downloaded woodstox and used in classpath with same result. I'm not getting it
Hide
Permalink
Tatu Saloranta added a comment -

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).

Show
Tatu Saloranta added a comment - 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).
Hide
Permalink
Martin Vanek added a comment -

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
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:313)
at com.ctc.wstx.stax.WstxOutputFactory.createXMLEventWriter(WstxOutputFactory.java:100)
at StaxWirdo.main(StaxWirdo.java:35)

Show
Martin Vanek added a comment - 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 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:313) at com.ctc.wstx.stax.WstxOutputFactory.createXMLEventWriter(WstxOutputFactory.java:100) at StaxWirdo.main(StaxWirdo.java:35)
Hide
Permalink
Tatu Saloranta added a comment -

I think I found the problem, finally. While the fix (to WSTX-139 is indeed fixed in trunk (4.0 series), 3.9 release must have been made before the fix got checked in. And I was mistaken in thinking that I had backported it to 3.2.x series (DOMWrappingWriter impl was added, but not ns-repairing part).

So, this will be resolved when I cut the first 4.0(pr1) version. I plan to do this soon now.

Show
Tatu Saloranta added a comment - I think I found the problem, finally. While the fix (to WSTX-139 is indeed fixed in trunk (4.0 series), 3.9 release must have been made before the fix got checked in. And I was mistaken in thinking that I had backported it to 3.2.x series (DOMWrappingWriter impl was added, but not ns-repairing part). So, this will be resolved when I cut the first 4.0(pr1) version. I plan to do this soon now.
Hide
Permalink
Tatu Saloranta added a comment -

Woodstox 3.9.1 release contains support for DOM-backed writer with namespace-repairing mode.

Show
Tatu Saloranta added a comment - Woodstox 3.9.1 release contains support for DOM-backed writer with namespace-repairing mode.
Hide
Permalink
Tatu Saloranta added a comment -

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).

Show
Tatu Saloranta added a comment - 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).
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.
Hide
Permalink
Tatu Saloranta added a comment -

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.

Show
Tatu Saloranta added a comment - 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.
Hide
Permalink
Tatu Saloranta added a comment -

Assuming problem was resolved (there are further DOM-related fixes in 3.2.7 release as well): reopen if there are remaining related issues.

Show
Tatu Saloranta added a comment - Assuming problem was resolved (there are further DOM-related fixes in 3.2.7 release as well): reopen if there are remaining related issues.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.