Default STAX xml writer generates invalid XML

[GoogleCodeExporter]

This generator generates elements, like:
 <foo aa="bb"></foo>
instead of generating
 <foo aa="bb"/>

As it turned out, .NET OData client uses XML Reader to parse xml. OData 
implementation asserts how the element is closed. It's necessary to have 
element closed in the short way: <foo />

I switched to XmlPull or DOM and it helped. Let's make STAX non-default xml 
reader/writer.

BTW. Current XmlWriterFactory implementation is a static field. Let's make it a 
component to avoid use of static fields and to allow easy-to-customize it.

Original issue reported on code.google.com by Eugene.P...@gmail.com on 12 Jan 2012 at 1:37

[GoogleCodeExporter]

Take a look to the test case for the case

Original comment by Eugene.P...@gmail.com on 12 Jan 2012 at 1:38

Attachments:

• patch_xml

[GoogleCodeExporter]

"OData implementation asserts how the element is closed. "

Can you elaborate on this?  Sounds like a bug in their implementation to me.

Original comment by john.spurlock on 12 Jan 2012 at 9:32

[GoogleCodeExporter]

True. It is the bug. I waste much time to debug it. 

I was working to support entity hasStream, so in the ATOM's entitry I had:
<entity>
 .. 
 <content type="application/zip" src="url" />
 <m:properties> ... </m:properties>
 ..
</entity>

That worked. But when I replace <content> element close method, i.e.
 <content type="application/zip" src="url" ></content>

.NET 4.0 client started to fail. (See AtomParser.cs, line 540, from 
System.Data.Services.Client, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089)

Original comment by Eugene.P...@gmail.com on 12 Jan 2012 at 10:33

[GoogleCodeExporter]

The fix also covered in the latest patch for Issue-111: 
https://code.google.com/p/odata4j-patches/source/browse/Issue-111-hasStream-in-m
etadata

Original comment by Eugene.P...@gmail.com on 16 Jan 2012 at 12:39