[#WSTX-104] Finish implementation of DOMWrappingWriter, to allow DOM trees to be built via XMLStreamWriter interface

Woodstox

Finish implementation of DOMWrappingWriter, to allow DOM trees to be built via XMLStreamWriter interface

Created: 21/Jan/07 01:24 PM Updated: 31/Oct/07 02:38 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Description

« Hide

Woodstox 3.2 includes a somewhat complete implementation of XMLStreamReader which reads from a DOM tree or fragment. Similarly, there is class DOMWrappingWriter, which should do the reverse (ie. build DOM tree/fragment based on calls via XMLStreamWriter). However, currently it's just a placeholder, and most of the functionality is not really implemented. It would be good to finish it for Woodstox 4.0.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Wilfred Springer added a comment - 30/Aug/07 08:20 AM

I spent the entire afternoon figuring out why I didn't get any data at all, only to find out afterwards that none of it is actually implemented. I suggest to either drop the class or complete it.

[ Permalink | « Hide ]

Wilfred Springer added a comment - 30/Aug/07 08:21 AM

BTW, I also think this is actually a bug, not an improvement.

[ Permalink | « Hide ]

Dan Diephouse added a comment - 30/Aug/07 11:05 AM

Yeah, thats bitten me too. In the mean time this class may help you:

http://fisheye6.cenqua.com/browse/celtixfire/trunk/common/common/src/main/java/org/apache/cxf/staxutils/W3CDOMStreamWriter.java?r=536402

[ Permalink | « Hide ]

Tatu Saloranta added a comment - 30/Aug/07 02:01 PM

Yes, this is not optimal. For what it's worth, WstxOutputFactory does NOT use it, and I was assuming users would always try to use that route instead of directly instantiating it. I was underestimating resourcfulness of the user base.

The reason class is there is/was mostly to retain skeleton – I was hoping to finish it up for 3.2 release. But since that didn't happen, it probably should have been moved to some other part of the source repository.

I think I will try to actually finish it up; either way, it needs to get resolved for 4.0 release, whenever that will happen.
Perhaps I could even create 3.2.2 if this did get completed.

[ Permalink | « Hide ]

Tatu Saloranta added a comment - 14/Sep/07 12:24 PM

Hi Wilfred! I started working on this issue, and hope to be able to get it in good enough working condition in a week. What I'm mainly worried is just testing: I will write simple unit tests, but since I don't have actual use case for this myself right now, I am hoping that perhaps you could help in testing in some way?
Also, thanks Dan for pointing me to the example – I will be perusing it, just need some additions to enable some level of namespace repairing as well as to nominally support stax2 interface (to the degree that's possible).

Finally, this may be a feature that could be backported to 3.2.x branch, so that users need not wait until 4.0 release, which may still take a while (like very late this year, or early 2008).

[ Permalink | « Hide ]

Tatu Saloranta added a comment - 31/Oct/07 02:37 PM

Implementation backported to 3.2 branch as well as trunk. Minimal unit tests exist.

[ Permalink | « Hide ]

Tatu Saloranta added a comment - 31/Oct/07 02:38 PM

Fix released as part of 3.2.2 (and will be part of 4.0), closing.