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
> >>
> >
> >
>
>
