XmlSeeAlso or provide your own instantiation of a Jaxbprovider. On Aug 2, 2013, at 9:38 AM, James Green <[email protected]> wrote:
> Pity I've not spotted a template project that gives all this. It is easier > to adapt and extend than to learn by documentation and by experimentation. > > I'm still having difficulty with JAX-WS and soap exceptions. Having > adjusted my @WebFault Exception subclasses to accept both a String message > and a custom Fault POJO, for some interfaces this works yet others I'm told > JAXB doesn't know how to map the Fault: > > Caused by: javax.xml.bind.MarshalException > - with linked exception: > [com.sun.istack.SAXException2: class com.myplace.saas.jaxws.Fault nor any > of its super class is known to this context. > javax.xml.bind.JAXBException: class com.myplace.saas.jaxws.Fault nor any of > its super class is known to this context.] > at > com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) > at > com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:178) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:537) > at > org.apache.cxf.jaxb.JAXBEncoderDecoder.marshallException(JAXBEncoderDecoder.java:381) > ... 26 more > Caused by: com.sun.istack.SAXException2: class com.myplace.saas.jaxws.Fault > nor any of its super class is known to this context. > javax.xml.bind.JAXBException: class com.myplace.saas.jaxws.Fault nor any of > its super class is known to this context. > at > com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) > at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:156) > at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:131) > at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:333) > at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:340) > at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:76) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) > at > com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) > ... 29 more > Caused by: javax.xml.bind.JAXBException: class com.myplace.saas.jaxws.Fault > nor any of its super class is known to this context. > at > com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:593) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) > ... 36 more > > Given this very class is used effectively elsewhere (in what I believe is > the same namespace, and everything is annotation-driven) I was a little > surprised to see the above. > > > > On 2 August 2013 16:18, Johan Edstrom <[email protected]> wrote: > >> What Sergey said. >> You are going to have different interfaces as one is a WSDL and one a >> WADL, re-using the types >> works like a charm though. That way you can model against the same >> dictionary and provide >> SOAP + XML, Rest + XML, Rest + JSON depending on request parameters and so >> on. >> >> Further combining CXF with Camel makes this even simpler since you don't >> really have to >> implement the interfaces per se. >> >> /je >> On Aug 2, 2013, at 9:13 AM, Sergey Beryozkin <[email protected]> wrote: >> >>> Hi >>> On 02/08/13 16:02, James Green wrote: >>>> Is there a project on say GitHub that demonstrates serious use of both >>>> JAX-RS and JAX-WS with proper exceptions being reported by both >> interfaces? >>>> >>>> It's one thing reading from the documentation and very narrow examples >> but >>>> it would be very useful to read the sources of a major finished project >> to >>>> see how it's done. >>>> >>>> It would be nice to see such an example proving both styles of interface >>>> via one set of classes with associated parameters and responses and >>>> exceptions. >>> Using a single (Java) interface to represent both JAX-WS & JAX-RS >> endpoints can be useful: >>> - as a proof of concept (ex, you have a SOAP endpoint, can the same >> service bean used to support RS calls ?, etc) >>> - when you have a SOAP endpoint and you have a strict requirement to >> reuse it for RS calls >>> >>> I'm saying it to suggest that really complex projects would likely have >> independent interfaces, as sometimes it can be difficult to use the same >> interface to represent different communication styles, or even to map >> non-WS URI + body to WS interface parameters. >>> >>> That said: as far as as the exceptions are concerned - this is the >> easiest part - for RS endpoint you just register one or few JAX-RS >> ExceptionMapper(s) and map them to whatever HTTP status code is appropriate >> in a given context >>> >>> Cheers, Sergey >>>> >>>> Any suggestions? >>>> >>>> Thanks, >>>> >>>> James >>>> >>> >>> >> >>
