With all due respect I think you were too hasty in dismissing the issue. I am using Axiom 1.2.8, which explains the difference in behaviour. And yes, the problem is still there.
Ok, I've reopened the issue.
(1) Spring WS is unusable with the latest release of Axiom, which, as I said, is likely to be the Axiom's fault in the first place, but it does not really change the fact.
The latest release I can find is 1.2.7 (http://repo2.maven.org/maven2/org/apache/ws/commons/axiom/axiom-api/), I am not sure where to get 1.2.8.
Could you try Axiom 1.2.7 and see if that works any better for you?
(2) Spring WS produces SOAP messages that are unnecessarily verbose. What is the point of declaring WSA namespace five times instead of one
True. I will fix it, and consider that the fix of this issue, if that's OK with you.
(3) Spring WS's behaviour is inconsistent. It registers namespaces at the fault level (soapenv:Fault), but for some reason does not do the same at header level (soapenv:Header)
This is actually Axiom doing it's thing. Whenever you call createSOAPFaultCode() on an Axiom SOAPFactory, it adds the namespace of the code at the fault level.
Moreover there is no way to customize the way Spring WS generates SOAP messages except for a wholesale fork of the entire AxiomSoap* class hierarchy.
You can always obtain a reference to the raw Axiom SOAPMessage object using getAxiomMessage(). You can manipulate that in any way you want to. I kept Spring-WS's the AxiomSoap* classes package private, because I cannot guarantee that the API will stay backwards compatible over time. In fact, changes in Axiom code already forced me to change the class hierarchy in the past.