Well, the verdict on that is that, yes, technically the form of the soap:header tag in the WSDL does not matter. I saved the WSDL to a file, altered the soap:header tag to the shorthand form, and ran WSDL2Java on the altered file but the generated classes have the same behavior as before.
I tried removing the soap:header tag completely and regenerated using WSDL2Java and that worked. I still have to add the actual header to the request in the client code that uses the Axis generated classes but at least it works.
Now I'm curious if this is a bug in Axis. Seems like it is not generating the appropriate code to handle the soap:body properly if there is a soap:header present in the WSDL. I searched the bugs for Axis on issues.apache.org but didn't find anything that matched this. Looks like all the effort has shifted to the yet unreleased Axis 2.
The problem that remains is that I don't have control over the published WSDL for the service. Working around this means I need to set up my build (
ant task) to retrieve the WSDL to a file, run a transform on it to zap the soap:header tag, and then run WSDL2Java.
Still hoping someone has a better suggestion.
-R