Hi Duncan On 06/10/12 08:35, Duncan Keysell (dkeysell) wrote:
Hi,I've inherited maintenance of a REST service that has a resource with the following interface: @GET @Path("/{etype}") @Description("Return a list of all the instances of {etype}") Object findEntities(@PathParam("etype") String entityType, @Context MessageContext mx); If I upgrade the service to use a recent version of CXF then it fails with the following message: "No message body writer has been found for response class Object." The service works with CXF versions 2.4.7, 2.5.0 and 2.6.0. It fails with the message, above, with versions after and including 2.4.8 and 2.6.1. Not sure at which version in 2.5.x stream it stops working, but it does. To check its not something I broke in my application code I took the jax_rs_basic project from the samples within the 2.6.0 and 2.6.1 distributions and changed the getCustomer method to return Object: @GET @Path("/customers/{id}/") public Customer getCustomer(@PathParam("id") String id) To @GET @Path("/customers/{id}/") public Object getCustomer(@PathParam("id") String id) I built this and found that it continues to work in 2.6.0 but fails in 2.6.1 with the "No message body writer has been found for response class Object." Is this an intentional change in CXF or should I raise a bug for this? Did I miss some configuration to handle this case? Do I need to start updating all my interfaces to return classes that are directly annotated with jaxb?
Thanks for the doing all the analysis above. The reason returning 'Object' stopped working is that now a class parameter that is passed to providers is determined exactly according to the method signature.
For example, say 'Customer' is returned where Customer is interface. Originally providers would be passed 'CustomerImpl.class' instead of Customer.class but this was causing a number of issues to do with attaching the configuration to all Customer classes at the provider level, example for supporting the proper marshalling of subclasses, etc...
I wonder though, given the example above, whether the change was entirely correct or not. I'll need to investigate more. Ideally, one would not return 'Object' but something more specific, example, abstract class/interface - this would also work well at the client (proxy) and WADL auto generation levels.
So, if possible try to move away from returning Object. In meantime I'll investigate the issue more. If it happens that the update was not correct then I'll introduce a contextual property for users to be able to tell the runtime what to do - with the original (earlier) approach done by default
Sergey
Thanks Duncan
-- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
