Hi,
On Dec 19, 2009, at 9:33 AM, John Calcote wrote:
> Hi,
>
> I'm having trouble understanding how content-types properly relate to resource methods.
>
> I'm writing a web service that uses JAXB bindings to send java objects in XML format over a ReSTful interface. I've defined two java objects in my message library: MessageA and MessageB. I send these messages with the same content type:
>
> "application/vnd.com.example-v1+xml"
>
> On the web service (also implemented using Jersey and JAXB), I have two resource methods:
You probably want a @Path, e.g.
@Path("/message")
> @POST
> @Consumes("application/vnd.com.example-v1+xml")
> public Response postMessageA(JAXBElement<MessageA> msg) {
> MessageA msgA = msg.getValue();
> ...
> }
>
@Path("/message/updated-event")
// or if you want to identify the message being updated, perhaps
//_at_Path("/message/{messageId}/updated-event")
> @POST
> @Consumes("application/vnd.com.example-v1+xml")
> public Response postConnectorUpdatedEvent(JAXBElement<MessageB> msg) {
> MessageB msgB = msg.getValue();
> ...
> }
>
> When I run this service, I get a startup error as the context is initialized indicating that I have ambiguous method resources of type HTTP POST, and the mime types of both are listed (the same, of course).
>
> My question is this: Clearly, I'm not supposed to use the same mime type in these two POST resource methods. What is the proper design for such a scenario? Should I have unique mime-types per message, or should I have a single resource method that somehow handles both messages.
>
> The first option would be simpler, but is it proper? The second option would require some JAXB gyrations of which I'm not yet familiar, such as determining the message type before casting to the proper java object class, or handing a base Message class from which both are derived, and using an internal field as a subclass selector (yuck). I'd really like Jersey to figure out the exact message type for me.
>
> Thanks in advance,
>
> John Calcote
> Sr. Software Engineer
> Novell, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>