Is this a bug with xsd:restrictions in Axis1_2RC3 ?

["Wild, Andrew" <AW...@boe.ca.gov>]

I'm connecting to a webservice deployed on Websphere server (who knows what
stack/version).  

Our client code generated with axis1_1 works fine without issues but when we
attempted to move to Axis1_2RC3 we ran into an issue where server would not
accept soap generated by new client code.  Some debugging later it turns out
the WSDL is using facet restrictions of the form:
...
	<xsd:simpleType name="MyType">
		<xsd:restriction base="xsd:string">
			<xsd:maxLength value="10"/>
		</xsd:restriction>
	</xsd:simpleType>
...

With old axis1_1 client code this sent SOAP with elements of form:
...
  <MyType xsi:type="ns:MyType"
xmlns:ns="http://mynamespace.com">12345</MyType>
...
  
With new axis12_RC3 client code it generated SOAP of form:
...
  <MyType xsi:type="xsd:string">12345</MyType>
...

More debugging and tracing later I figured out that the type information
sent comes from the static metadata section of client code which is
generated by JavaBeanHelperWriter.java#342 during WSDL2Java generation.

My question is how/why did the behaviour of the metadata generation change?
Is this a bug?  or is there some switch I am unaware of I should be using
for WSDL2Java with axis1_2RC3?

I've read something about restrictions not being required as per JSR101 and
frankly I think the server should simply accept the wider type and enforce
the restriction only if the data fails the restriction but I don't control
the WSDL or the service.  Can someone think of a clean fix for this or am I
going to be forced to hand doctor the client code or stick with Axis1_1?

Thanks,
Andrew Wild
Contractor TSD-AD