Manipulating namespace prefixes in SAAJ / raw xml access within SAAJ

My SAAJ-based client generates the following XML and sends it to a .NET web service:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<AuthenticationHeader xmlns="http://www.w3.org/2001/XMLSchema-instance">
<Password xmlns="http://schemas.datacontract.org/2004/07/">temp123</Password>
<UserName xmlns="http://schemas.datacontract.org/2004/07/"&开发者_如何学运维gt;temp321</UserName>
</AuthenticationHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<GetTracks xmlns="http://tempuri.org/">
  <TrackName>baby</TrackName><ArtistID>0</ArtistID><AlbumID>0</AlbumID><Start>0</Start><Count> 20</Count>
</GetTracks></SOAP-ENV:Body></SOAP-ENV:Envelope>

The problem I am experiencing is that for the AuthenticationHeader element I must have a prefix defined but it should not be appended to the very beginning. This is exactly what I need to get generated in order not to get an error from the web service:

<AuthenticationHeader xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

While if I generate a prefix during the Name creation, it is automatically added after the xmlns attribute and at the very beginning of the element.

I tried to poke around with the whole javax.xml.soap package but wasn't able to find anything that could help me to get around this. Can you give me a hint on which direction to go in order to get such an xml generated?

On a side note, I wonder if this is even valid behavior for a web service to reject valid xml like this? What is the motivation for such an interpretation behavior?

Thank you!

Java SOAP APIs generally assume spec compliance from the service their talking to, and so things like fine-grained prefix control don't get exposed via the API, since there should be no reason to care.

In previous cases like this, I've often had to resort to manual construction of the SOAP DOM object, which is hideously painful.

More recently, I've had reasonably good luck with getting Spring WebServices to produce exactly what I'm after. It abstracts the SAAJ API, whilst still providing hooks to get down and dirty with the DOM at the XML level. I suggest giving it a try and see what you can come up with.