JiBX

XMLWriterBase's reset() does not reset namespace prefixes

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: core
  • Labels:
    None
  • Number of attachments :
    0

Description

Say you are writing to an output stream with namespace prefixes.

writer.startTagNamespaces(2, "stream", new int[]

{ 2, 3 }

, new String[]

{ "stream", "" }

);

When you reset the writer either by calling reset() or setOutput(), the namespace prefixes are not closed. You must close the tag by calling endTag() in order for the namespaces to be closed properly. However, it is not guaranteed that the endTag() will be called for each corresponding startTagNamespaces().

The situation can occur either if the stream is unexpectedly closed or if a setOutput() is explicitly called before writing out the end tag. In such cases, the namespaces must be closed and resetted in order for the writer to be reused. Otherwise, the writer will always think those namespaces have already been defined, thus making the xml writer not recyclable as intended.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chris Chen added a comment -

On a side note.

closeNamespaces() should also do a sanity check.

If m_namespaceStack.pop() returns a null, then the method should either do nothing or reset the the stack and depth. Currently, if pop() return null, likely, the method will throw a NPE.

Show
Chris Chen added a comment - On a side note. closeNamespaces() should also do a sanity check. If m_namespaceStack.pop() returns a null, then the method should either do nothing or reset the the stack and depth. Currently, if pop() return null, likely, the method will throw a NPE.
Hide
Permalink
Dennis Sosnoski added a comment -

I don't see how this is a bug, though I'm open to persuasion. It is not intended that the user be able to call reset() or setOutput() in the middle of a marshalling operation and then continue on, which is how I understand your problem report. The reset() documentation refers explicitly to the serial reusability of XMLWriterBase instances when reset() is called. If the documentation is not clear that these methods can only be used between documents I can add a note to this effect.

It looks to me like reset() works properly.

Show
Dennis Sosnoski added a comment - I don't see how this is a bug, though I'm open to persuasion. It is not intended that the user be able to call reset() or setOutput() in the middle of a marshalling operation and then continue on, which is how I understand your problem report. The reset() documentation refers explicitly to the serial reusability of XMLWriterBase instances when reset() is called. If the documentation is not clear that these methods can only be used between documents I can add a note to this effect. It looks to me like reset() works properly.
Hide
Permalink
Chris Chen added a comment -

I must admit that my situation may be calling a reset() or setOutput() in the middle of a marshalling operation. However, on a more generalized level, what if there was an error during the marshalling stage? For instance, what if the marshalling code throws a JiBXException after opening a start tag but before an end tag is reached? I cannot think of an example at the moment. However, I think the reasoning is not just about calling reset() or setOutput() in the middle of a marshalling operation. If an exception occurs in any way during the marshalling, it would not be possible to reuse the Writer anymore. A new instance would have to be created.

When I first saw reset(), I thought that the method is supposed to reset the entire writer back to the original when it was first instantiated (that was sort of my definition of reset) so that it can be reused to marshall another document. Of course, this is the case if the document marshalling was successful each time, but I believe it is not a guarateed situation. Exceptions may possibly occur during marshalling, in which case it would be ideal to reset the writer back to the pristine state.

I realize that this is not a bug as you said. My current way is to close off the writer and instantiate a new writer. I figured it would be more efficient if the writer can be recycled and reused under almost any situation.

Show
Chris Chen added a comment - I must admit that my situation may be calling a reset() or setOutput() in the middle of a marshalling operation. However, on a more generalized level, what if there was an error during the marshalling stage? For instance, what if the marshalling code throws a JiBXException after opening a start tag but before an end tag is reached? I cannot think of an example at the moment. However, I think the reasoning is not just about calling reset() or setOutput() in the middle of a marshalling operation. If an exception occurs in any way during the marshalling, it would not be possible to reuse the Writer anymore. A new instance would have to be created. When I first saw reset(), I thought that the method is supposed to reset the entire writer back to the original when it was first instantiated (that was sort of my definition of reset) so that it can be reused to marshall another document. Of course, this is the case if the document marshalling was successful each time, but I believe it is not a guarateed situation. Exceptions may possibly occur during marshalling, in which case it would be ideal to reset the writer back to the pristine state. I realize that this is not a bug as you said. My current way is to close off the writer and instantiate a new writer. I figured it would be more efficient if the writer can be recycled and reused under almost any situation.
Hide
Permalink
Dennis Sosnoski added a comment -

I still don't see an issue here, so I'm marking this resolved/won't fix. If a marshalling operation fails you can reuse the writer without a problem as far as I can see, since all the data structures are properly cleaned up by the reset() operation. Naturally, the output stream you were writing previously won't be a valid XML document, and you need to discard the partial output document and set a new stream for the new marshalling operation - but that's just the nature of XML.

Show
Dennis Sosnoski added a comment - I still don't see an issue here, so I'm marking this resolved/won't fix. If a marshalling operation fails you can reuse the writer without a problem as far as I can see, since all the data structures are properly cleaned up by the reset() operation. Naturally, the output stream you were writing previously won't be a valid XML document, and you need to discard the partial output document and set a new stream for the new marshalling operation - but that's just the nature of XML.

People

  • Assignee:
    Dennis Sosnoski
    Reporter:
    Chris Chen
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: