You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by James Green <ja...@gmail.com> on 2013/08/02 17:02:47 UTC
Decent real-world project source?
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.
Any suggestions?
Thanks,
James
Re: Decent real-world project source?
Posted by Johan Edstrom <se...@gmail.com>.
XmlSeeAlso or provide your own instantiation of a Jaxbprovider.
On Aug 2, 2013, at 9:38 AM, James Green <ja...@gmail.com> 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 <se...@gmail.com> 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 <sb...@gmail.com> 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
>>>>
>>>
>>>
>>
>>
Re: Decent real-world project source?
Posted by James Green <ja...@gmail.com>.
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 <se...@gmail.com> 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 <sb...@gmail.com> 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
> >>
> >
> >
>
>
Re: Decent real-world project source?
Posted by Johan Edstrom <se...@gmail.com>.
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 <sb...@gmail.com> 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
>>
>
>
Re: Decent real-world project source?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>