You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Johnson, Eric" <Er...@iona.com> on 2008/06/05 23:32:36 UTC
JAX-WS Handler question
In the Handler demo both handlers have init() and destroy() methods. I
cannot find them in the spec or the JAX-WS handler API docs. What are
they for?
Re: CXF & JSON Response
Posted by Coder One <co...@yahoo.com>.
--- On Fri, 6/6/08, Sergey Beryozkin <se...@iona.com> wrote:
>> Current JSON provider on the trunk works with a JAXBContext
> in tandem and it can only acquire a JAXBContext
> if XMLRootElement annotation is available. Once the patch
> I'm slowly working upon is commited, it will be able to
> acquire contexts
Fantastic!
> Trying to provide your own message provider can be a
> reasonable solution. Runtime won't always be able to do
> the (de)serialzation
> the way you expect (dur to a custom nature of a given type
> or due to the fact it's not capable of doing the given
> moment of time)
This worries me a bit. Our "standard" for remote interfaces is to use only primitive java data types (byte, short, long, String, float, double) along with arrays, possibly List and Map, and that's it. A standard message provider ought to handle that right? Trying to think of practices to avoid so we do not have to write custom message writers.
> and in such cases being able to provide your own provider
> is really handly
Yes...but that's a lot of work :) A major benefit with a framework such as CXF is the automated data binding...:)
Thanks again!
> Cheers, Sergey
>
>
> >I got my CXF JAX-RS service going but the response is
> cryptic: No message body writer found for response class :
> AlertMsg.
> >
> > Browsing the archive, I found the solution, but it
> looks "roundabout". I don't like the need to
> annotate my response bean with
> > JAXB stuff. An analogy is that Web Services (SOAP) do
> not require annotations/registration of writers of the
> response beans...why
> > CXF/JAX-RS? Thanks...
> >
> > @GET
> > @Path("/getAlertMsg/{aId}")
> > @ProduceMime("application/json")
> > public AlertMsg
> getAlertMsg(@PathParam("aId") String aId)
> >
> >
> > public class AlertMsg implements java.io.Serializable
> > {
> > private String a;
> > private String[] b;
> > }
> >
> >
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
Re: CXF & JSON Response
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Current JSON provider on the trunk works with a JAXBContext in tandem and it can only acquire a JAXBContext
if XMLRootElement annotation is available. Once the patch I'm slowly working upon is commited, it will be able to acquire contexts
if an ObjectFactory is available in a package and thus you'd be able to avoid annotating classes like AlertMsg.
If you'd like to avoid dealing with JAXB at all then another alternative is to use Aegis and I'm considering adding a basic Aegis
provider as well.
Trying to provide your own message provider can be a reasonable solution. Runtime won't always be able to do the (de)serialzation
the way you expect (dur to a custom nature of a given type or due to the fact it's not capable of doing the given moment of time)
and in such cases being able to provide your own provider is really handly
Cheers, Sergey
>I got my CXF JAX-RS service going but the response is cryptic: No message body writer found for response class : AlertMsg.
>
> Browsing the archive, I found the solution, but it looks "roundabout". I don't like the need to annotate my response bean with
> JAXB stuff. An analogy is that Web Services (SOAP) do not require annotations/registration of writers of the response beans...why
> CXF/JAX-RS? Thanks...
>
> @GET
> @Path("/getAlertMsg/{aId}")
> @ProduceMime("application/json")
> public AlertMsg getAlertMsg(@PathParam("aId") String aId)
>
>
> public class AlertMsg implements java.io.Serializable
> {
> private String a;
> private String[] b;
> }
>
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
CXF & JSON Response
Posted by Coder One <co...@yahoo.com>.
I got my CXF JAX-RS service going but the response is cryptic: No message body writer found for response class : AlertMsg.
Browsing the archive, I found the solution, but it looks "roundabout". I don't like the need to annotate my response bean with JAXB stuff. An analogy is that Web Services (SOAP) do not require annotations/registration of writers of the response beans...why CXF/JAX-RS? Thanks...
@GET
@Path("/getAlertMsg/{aId}")
@ProduceMime("application/json")
public AlertMsg getAlertMsg(@PathParam("aId") String aId)
public class AlertMsg implements java.io.Serializable
{
private String a;
private String[] b;
}
Re: JAX-WS Handler question
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 5, 2008, at 5:32 PM, Johnson, Eric wrote:
> In the Handler demo both handlers have init() and destroy() methods. I
> cannot find them in the spec or the JAX-WS handler API docs. What are
> they for?
Honestly, they are probably just leftovers from being ported from
version to version to version. The very early incarnations of the JAX-
WS spec were extenstions of the JAX-RPC spec (JAX-WS was originally
jsut JAX-RPC 1.1, then 2.0, then renamed). The JAX-RPC handlers had
specific lifecycle methods like init and destroy. Since Celtix was
started before JAX-WS 2.0 was finalized and was closer to the JAX-RPC
spec (and several of the samples were taken from IONA's JAX-RPC based
product), it's quite likely those methods are just there due to
historical reasons.
Feel free to remove them.
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: JAX-WS Handler question
Posted by Glen Mazza <gl...@verizon.net>.
I think this[1] is the class you're referring to. I don't know what
those methods are for, but as handlers are just an interface it's OK for
implementations of them to have additional methods. I wouldn't worry
too much about it. Just FYI, here's some research I did on
interceptor/handler differences[2].
HTH,
Glen
[1] http://tinyurl.com/3s4tlf
[2] http://www.jroller.com/gmazza/entry/apache_cxf_switching_between_jax
2008-06-05 Johnson, Eric wrote:
> In the Handler demo both handlers have init() and destroy() methods. I
> cannot find them in the spec or the JAX-WS handler API docs. What are
> they for?