[jdom-interest] [Fwd: Bug in JDOM serialization]

[Michael Lipp]

Elliotte Rusty Harold wrote:
> At 2:29 PM -0800 3/27/03, Jason Hunter wrote:
> 
>> As we just noticed, the additional namespaces in the JDOM element are 
>> transient. This is bad.
> 
> 
> 
> No, it's not. Only the fields are transient, not the information. The 
> fields are transient because JDOM uses the flyweight design pattern to 
> hold namespaces. Using transient ensures that deserialization won't 
> actually create duplicates of things that are supposed to have only one 
> instance.
> 
> However, if you look deeper in the code you'll notice that Element has 
> custom readObject() and writeObject() methods that do store the 
> additional namespaces in a way that's consistent with flyweights, so 
> nothing is ever lost.

Well, if it was true that nothing is ever lost, I would never have sent 
a mail.

Something is lost. While the deserialized JDOM tree is still a perfectly 
valid tree, the original position of the namespace declaring attribute 
(resp. the complete declaration) is lost. This does not invalidate the 
tree but it causes problems when using the tree together with SOAP toolkits.

WSDL uses qualified names in type attributes. This is not "sanctioned" 
by XML because neither XML nor the namespace standard support semantics 
for values of attributes. But nevertheless, that is what WSDL does.

So what happens if a SOAP toolkit finds 'attr="myschema:Element1"'? It 
searches the tree up for a namespace declaration 'xmlns:myschema="..."'. 
If it doesn't find this, it fails (note that the WSDL does not have to 
include any element or attribute with prefix "myschema", so from the DOM 
tree's perspective there is no problem that the namespace declaration 
never appears).

This is what makes the declarations of namespaces at their original 
position important, even if the declared namespaces are never used for 
element or attribute names. And this is why using deserialized JDOM as 
input for SOAP toolkits (namely Axis) fails.

Of course, you may argue that the usage of attributes like this by WSDL 
is non-standard. OK. For us this is no problem, we leave the 
serialization/deserialization wrapper that we had to program in our 
code. But it would be nice to include a hint in the documentation 
("Serializing and Deserializing WSDL will fail") because it took us some 
time to find out why our SOAP suddenly wasn't working any more after an 
EJB had been passivated...

  - Michael