• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

@WebService method returning a custom class containing a HashMap / JAX-WS

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks in advance.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic