File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes javax.xml.bind.JAXBException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "javax.xml.bind.JAXBException" Watch "javax.xml.bind.JAXBException" New topic


Grady Jamyson
Ranch Hand

Joined: Aug 04, 2002
Posts: 42
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?
Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
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!"
    I agree. Here's the link:
    subject: javax.xml.bind.JAXBException
    It's not a secret anymore!