StopSpam wrote:
> Right, but in the case of an XML Protocol which envelops other XML data,
> it might not be desirable to inherit name spaces and other context into
> designated elements. This is also true in my case, where the xml wild card
> content inside the XMLData element should be independent.
>
> For a more detailed explanation of the problem please refer to
> http://www.w3.org/TR/xml-exc-c14n/#sec-ExclusiveNeed
Thanks for the pointer. I didn't know that the signature is sensitive to
the presence of unused namespace declarations.
I'll see what I can do about this in 2.0. It seems like this needs a
spec-level attention.
> Btw. how is this solved for SOAP? I'm not too much into SOAP, but my problem
> seems similar to SOAP envelopes and I think jaxrpc also uses jaxb.
I'm curious, too. You might consider posting to users_at_jax-rpc.dev.java.net?
>>If you need to keep the original infoset intact, you can first unmarshal
>>the whole document to DOM, then unmarshal it into JAXB. That way, you
>>can perform the signature verification against DOM.
>
> Thanks a lot for the fast reply and I think this might be possible,
> but the problem to extract a node without it's context remains.
> However Document.adoptNode() might do the trick.
If you have a complete DOM tree, then that would capture all the
namespace decls and so on intact. If you look at a particular element
without checking its ancestors, it seems to me that you get the desired
effect.
The downside I see is that you have to work with the DOM API to get to
the part that you want to verify the signature, which is the part that I
mentioned will be easier in 2.0.
> P.S.: Is it possible to do the dom binding from a customization
> file as well, and how is the Syntax?
Anything you can do with inline annotation, you can do with an external
file. It's just like every other annotations. I think there's a plenty
of samples in the distribution bundle.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com