I am hoping someone else has seen this issue before.
I have JAX-WS endpoint service that has a method:
The hand coded BookOrder class looks like this:
We want to be able to compile our Java Bean objects into a "shared jar" that can be used by both the Client and Service sides of the wire - this is unusual, but in this case, the project owns both ends of the wire so they want to enforce consistent use of these objects. In the case of custom java classes, this approach works fine as we have done it w/o a problem as long as none of the classes use Map types (like HashMap).
The generated version of BookOrder.java looks like this (below) - (after running wsimport pointing at the WSDL served back from the running endpoint service). Of course the generated ObjectFactory.java file is based on this "generated" version of the Java bean classes. Now the BookOrder.java in the shared jar file and this generated BookOrder.java are different in that wsimport and JAXB have created a class w/ some inner class constructs to handle the ORIGINAL HashMap defined. This is where the problem occurs because when attempting to compile the client side code, we run into issues all resulting from this DIFFERENCE in mapping.
(removed most of the generated COMMENTs to shorten this post - it's already long enough :-) )
The XML schema generated when the service endpoint was deployed (in addition to its WSDL) had the following definition for BookOrder:
Is there any way, using a custom binding file passed to wsimport to force the client-side generation process to end up with consistent classes such that the generated ObjectFactory.java can still work w/ our "shared" compiled JAR file containing our hand-coded BookOrder.java class? In other words, can we get the client-side generated BookOrder.java to match the original? I'd appreciate any suggestion or example where someone may have done this...assuming it is even possible.
In general, if we have Arrays or List types, none of this is a problem...but w/ Map types, it falls apart.