Woodstox

RepairingNsStreamWriter class adds a new prefix to parent SimpleOutputElement object.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

String ns1 = "urn://namespace1";
String ns2 = "urn://namespace2";
writer.writeStartDocument();
writer.writeStartElement(ns1, "rootElement");
writer.writeStartElement(ns2, "firstChild");
writer.writeEndElement();
writer.writeStartElement(ns2, "secondChild");
writer.writeEndElement();
writer.writeEndElement();
writer.writeEndDocument();
writer.close();

the code above is expected to give us

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1">
<wstxns2:firstChild xmlns:wstxns2="urn://namespace2" />
<wstxns3:secondChild xmlns:wstxns3="urn://namespace2" />
</wstxns1:rootElement>

or

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1" xmlns:wstxns2="urn://namespace2">
<wstxns2:firstChild />
<wstxns2:secondChild />
</wstxns1:rootElement>

But, wstx writer create a document such as

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1">
<wstxns2:firstChild xmlns:wstxns2="urn://namespace2" />
<wstxns2:secondChild/>
</wstxns1:rootElement>

which has missing ns prefix delaraction at the element named secondChild.

For respects of readability and document size, it would be better all namespace declaration are located at the root element.
But XMLStreamWriter doesn't know which xml namespace prefix delaration would be used and when it would be.

Anyway, I found a problem in the method, writeStartOrEmpty(String localName, String nsURI) in RepairingNsStreamWriter class.

RepairingNsStreamWriter writes StartElement in this order.
1) add a ns-prefix mapping to current element. (it would be parent element)
2) create child element <-- The subject of writeStartElement.
3) current element = child element
4) set ns-prefix of current element

I changed the orthe this way,
1) create child element with null prefix.
2) current element = child element
3) add a ns-prefix mapping to current element
4 set ns-prefix of current element

see a attached source file.( writeStartOrEmpty(String localName, String nsURI) )

Activity

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

This does indeed look like a bug (assuming output you added is what is produced).

One quick question: which version is this against?

Also, thank you for the patch! That is much appreciated.

Show
Tatu Saloranta added a comment - This does indeed look like a bug (assuming output you added is what is produced). One quick question: which version is this against? Also, thank you for the patch! That is much appreciated.
Hide
Permalink
Tatu Saloranta added a comment -

Never mind, seems to be present in trunk and 3.2 at least.

I went ahead and added unit test similar to the one suggested into StaxTest project, compiled and added to Woodstox, to verify the eventual fix. Fix explanation makes sense given the problem.

Show
Tatu Saloranta added a comment - Never mind, seems to be present in trunk and 3.2 at least. I went ahead and added unit test similar to the one suggested into StaxTest project, compiled and added to Woodstox, to verify the eventual fix. Fix explanation makes sense given the problem.
Hide
Permalink
Yoon-Je Choi added a comment -

Yes, it is present in 3.2 at least.

Nowdays, I'm working on creating a kind of XML binding.
It generates code which handle marshalling and unmarshalling with stax parser.
It should be capable of handling both byte[] and Node so that I use both RepairingNSStreamWriter (for byte[]) and DOMWrappingWriter.

But now, reparingNS option of DOMWrappingWriter is not available yet.
If reparingNS option of DOMWrappinWriter could be enabled, the XML biding I working on will not concern which object (byte[] or Node) it will handle.
(Because It would handle XML Document with XMLStreamWriter and XMLStreamReader interface.)
Otherwise I cannot use same code for marshaller for byte[] and marshaller for Node.

So, I wonder When would be this function, DOMWrappingWriter capable of reparingNS, released.
If it's not scheduled or so, I should add a sort of namespace context function to my engine.
(or as I mentioned, I may implement Node marshaller without XMLStreamWriter interface).

Anyway, thank you for fixing my issues.

Show
Yoon-Je Choi added a comment - Yes, it is present in 3.2 at least. Nowdays, I'm working on creating a kind of XML binding. It generates code which handle marshalling and unmarshalling with stax parser. It should be capable of handling both byte[] and Node so that I use both RepairingNSStreamWriter (for byte[]) and DOMWrappingWriter. But now, reparingNS option of DOMWrappingWriter is not available yet. If reparingNS option of DOMWrappinWriter could be enabled, the XML biding I working on will not concern which object (byte[] or Node) it will handle. (Because It would handle XML Document with XMLStreamWriter and XMLStreamReader interface.) Otherwise I cannot use same code for marshaller for byte[] and marshaller for Node. So, I wonder When would be this function, DOMWrappingWriter capable of reparingNS, released. If it's not scheduled or so, I should add a sort of namespace context function to my engine. (or as I mentioned, I may implement Node marshaller without XMLStreamWriter interface). Anyway, thank you for fixing my issues.
Hide
Permalink
Tatu Saloranta added a comment -

Cool, sounds like an interesting and useful tool/library that you are working on.
Like I said, I should be able to fix the problem as per your suggestion pretty soon now (hopefully over the weekend). And since there have been a few other fixes submitted, should release 3.2.3 as well (something I hadn't planned to do, but bugs need to be squashed ASAP).

As to DOM writer: unfortunately time I can spend on woodstox is somewhat limited now. Also, finishing that part up was not very high on my list, so I wasn't expecting it to be done very soon.
But if you want it to get done, there are 2 things that would help:

(a) If you can file another issue (new feature or improvement) in Jira for implementing namespace-repairing mode for DOMWrappingWriter, that would help (and of course you can also vote for it). That way it's easier for me to track what kinds of things users want. I will try to prioritize things so that it's partially based on wishes of users, not just my own preferences.
(b) Alternatively, if you (or any other woodstox user) could contribute an implementation, I would be happy to integrate it in. It should not be very hard to implement, although not trivial either (if it was trivial, I would have finished it right away).

One possibility is that if you do end up writing your own namespace context, perhaps that might help in someone implementing equivalent functionality within Woodstox?

At any rate, thank you for reporting the problems, as well as patience in getting them resolved. I really appreciate it, since DOM compatibility part was not heavily used or tested earlier.

Show
Tatu Saloranta added a comment - Cool, sounds like an interesting and useful tool/library that you are working on. Like I said, I should be able to fix the problem as per your suggestion pretty soon now (hopefully over the weekend). And since there have been a few other fixes submitted, should release 3.2.3 as well (something I hadn't planned to do, but bugs need to be squashed ASAP). As to DOM writer: unfortunately time I can spend on woodstox is somewhat limited now. Also, finishing that part up was not very high on my list, so I wasn't expecting it to be done very soon. But if you want it to get done, there are 2 things that would help: (a) If you can file another issue (new feature or improvement) in Jira for implementing namespace-repairing mode for DOMWrappingWriter, that would help (and of course you can also vote for it). That way it's easier for me to track what kinds of things users want. I will try to prioritize things so that it's partially based on wishes of users, not just my own preferences. (b) Alternatively, if you (or any other woodstox user) could contribute an implementation, I would be happy to integrate it in. It should not be very hard to implement, although not trivial either (if it was trivial, I would have finished it right away). One possibility is that if you do end up writing your own namespace context, perhaps that might help in someone implementing equivalent functionality within Woodstox? At any rate, thank you for reporting the problems, as well as patience in getting them resolved. I really appreciate it, since DOM compatibility part was not heavily used or tested earlier.
Hide
Permalink
Tatu Saloranta added a comment -

Fixed along the lines proposed (did reorder things a bit to remove some duplicate code as well).
Applied to 3.2 branch as well as trunk.

Show
Tatu Saloranta added a comment - Fixed along the lines proposed (did reorder things a bit to remove some duplicate code as well). Applied to 3.2 branch as well as trunk.
Tatu Saloranta made changes -
Field Original Value New Value
Resolution Fixed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
Hide
Permalink
Tatu Saloranta added a comment -

Fix included in 3.2.3 release

Show
Tatu Saloranta added a comment - Fix included in 3.2.3 release
Tatu Saloranta made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Yoon-Je Choi
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: