• 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
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

javax.xml.bind.JAXBException

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am writing a web service client to pass a custom type to the server but get a error message,

[javax.xml.bind.JAXBException: class com.example.mypachage.WineData nor any of its super class is known to this context.]

The server side code is as following,


And the client code is as following,




Is there anything I need to know while using the custome type as parameter passing around web services?
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are trying to impose Object-Orientation on the Service-Oriented domain.

Even in the OO domain your method is lying (potentially resulting in a class cast exception during runtime). It advertises that it will accept any "Object" which implies that it will only use the interface of "Object" and then it turns around and promptly downcasts to "WineData" - so it should really be up front and only accept WineData objects.

Services exchange messages (not objects); polymorphism relates directly to the Liskov Substitution Principle:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.



  • Messages unlike objects do not manifest behavior.
  • Messages don't hide anything - all the data is public.


  • It follows that if a service advertises that it will accept a super-type then the client will only send the data that is part of the super-type (because that is all that is needed). Therefore it would be impossible for the service to downcast the content of the message.

    To be able to do what you are trying to do the service would have to include all the supported sub-types in the service contract - however there is simply no point in doing that if it is only going to use the data that is present in the super-type (which is what the contract is promising to do).

    Polymorphism is a concept that does not translate well into the Service-Oriented domain. Polymorphism requires inheritance and Services themselves do not support inheritance as that would interfere with their Service Autonomy and increase their inter-service coupling (p.459 SOA Principles of Service Design). Therefore you shouldn't expect inheritance to be supported by the messages or the elements that are used inside the messages.

    Ironically XML Schema does support inheritance to maximize reuse which means that some tools will use it inside of the service contract. However practical experience has shown that use of XML Schema inheritance/polymorphism features will usually adversely affect interoperability and lead to increased coupling - so use of XML Schema inheritance/polymorphism is in fact discouraged (p.44 SOA in Practice).

    "Toto, I've got a feeling we're not in Kansas anymore."

    "Oh dear! I keep forgetting I'm not in Kansas!"
     
    Dinner will be steamed monkey heads with a side of tiny ads.
    Gift giving made easy with the permaculture playing cards
    https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
    reply
      Bookmark Topic Watch Topic
    • New Topic