CXF
  1. CXF
  2. CXF-3617

Automatic Type Converters for Restful Clients

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: JAX-RS
    • Labels:
      None
    • Estimated Complexity:
      Moderate

      Description

      Given the following interface:

      @POST
      @Path( "execute" )
      @Produces( "application/json" )
      MyObject execute( MyObject myObject );
      

      One must provide MessageBodyReader\Writer or face the following exception:

      Exception in thread "main" org.apache.cxf.interceptor.Fault: .No message body writer found for class : class com.company.datatype.normal.MyObject.
          at org.apache.cxf.jaxrs.client.ClientProxyImpl$BodyWriter.handleMessage(ClientProxyImpl.java:523)
          at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
          at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:438)
          at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:177)
          at $Proxy13.execute(Unknown Source)
          at com.company.JaxTestClient.main(JaxTestClient.java:26)
      

      Other competing libraries (such as Restlet) support automatic type mapping out of the box via XStream and Jackson. Given CXF's compliance to JAX-RS it would be helpful if this boilerplate type code were given out of the box too.

      See here for more information:
      http://stackoverflow.com/questions/6312030/cxf-no-message-body-writer-found-for-class-automatically-mapping-non-simple-re

        Activity

        Hide
        Sergey Beryozkin added a comment -

        Sorry - saw this issue but got sidetracked,

        You can register Jackson provider or xStream one (as suggested at StackOverflow page you linked to) when creating WebClient.
        Do you agree this is a non-fix issue, but mainly a configuration issue ?

        Show
        Sergey Beryozkin added a comment - Sorry - saw this issue but got sidetracked, You can register Jackson provider or xStream one (as suggested at StackOverflow page you linked to) when creating WebClient. Do you agree this is a non-fix issue, but mainly a configuration issue ?
        Hide
        Shaun Elliott added a comment -

        No, I think a better solution would be automatic registration. This is how the Restlet library does it. You don't have to worry about mappings.

        Furthermore, I would think a generic MessageBody[Reader|Writer] like the accepted answer would be part of the library already. I don't understand why it is not (though, admittedly, I am ignorant to some of the workings of restful web service clients).

        Show
        Shaun Elliott added a comment - No, I think a better solution would be automatic registration. This is how the Restlet library does it. You don't have to worry about mappings. Furthermore, I would think a generic MessageBody [Reader|Writer] like the accepted answer would be part of the library already. I don't understand why it is not (though, admittedly, I am ignorant to some of the workings of restful web service clients).
        Hide
        Sergey Beryozkin added a comment -

        > No, I think a better solution would be automatic registration. This is how the Restlet library does it. You don't have to worry about mappings.

        Well, we do ship a default JSONProvider which assumes objects are JAXB beans - those will be automatically mapped. On top of it we can customize a lot JSONProvider works with data. Thus we can't drop it and replace with Jackson or XMLStream provider.
        We can also application/x+bar medium type and MyObject - would you expect it automatically mapped as well ?

        The point I'm making is that we ship a default JSONProvider. And registering custom or existing 3rd party providers is very easy. Even if CXF did ship say XStream provider then you;d still need to register it explicitly for it to be preferred to the default JSONProvider - but I don't think we can afford shipping multiple JSON providers

        Show
        Sergey Beryozkin added a comment - > No, I think a better solution would be automatic registration. This is how the Restlet library does it. You don't have to worry about mappings. Well, we do ship a default JSONProvider which assumes objects are JAXB beans - those will be automatically mapped. On top of it we can customize a lot JSONProvider works with data. Thus we can't drop it and replace with Jackson or XMLStream provider. We can also application/x+bar medium type and MyObject - would you expect it automatically mapped as well ? The point I'm making is that we ship a default JSONProvider. And registering custom or existing 3rd party providers is very easy. Even if CXF did ship say XStream provider then you;d still need to register it explicitly for it to be preferred to the default JSONProvider - but I don't think we can afford shipping multiple JSON providers
        Hide
        Shaun Elliott added a comment -

        Right, I've looked over the JAXB default binding and that works well if your objects are already annotated as such. However, if they are not what then? You must register readers\writers for all other objects? What about the solution provide by the stackoverflow post? Could something like that not be provided in the library? I mean, ultimately from an end user perspective I don't care too much which provider is used: XStream, Jackson, etc - any would be fine. I just want it to handle object serialization over the wire seamlessly. I hope this makes sense

        Show
        Shaun Elliott added a comment - Right, I've looked over the JAXB default binding and that works well if your objects are already annotated as such. However, if they are not what then? You must register readers\writers for all other objects? What about the solution provide by the stackoverflow post? Could something like that not be provided in the library? I mean, ultimately from an end user perspective I don't care too much which provider is used: XStream, Jackson, etc - any would be fine. I just want it to handle object serialization over the wire seamlessly. I hope this makes sense
        Hide
        Sergey Beryozkin added a comment -

        No - you just need to register a provider which is capable of mapping all the objects you are dealing with to/from format which needs to be supported.

        Show
        Sergey Beryozkin added a comment - No - you just need to register a provider which is capable of mapping all the objects you are dealing with to/from format which needs to be supported.
        Hide
        Shaun Elliott added a comment -

        Couldn't this be provided? My guess is that other libraries most likely use reflection to do it by default.

        Show
        Shaun Elliott added a comment - Couldn't this be provided? My guess is that other libraries most likely use reflection to do it by default.
        Hide
        Sergey Beryozkin added a comment -

        No. CXF can not magically support all the media types/formats/mappings - just register a custom provider.
        I'm going to close this as won't fix...

        Show
        Sergey Beryozkin added a comment - No. CXF can not magically support all the media types/formats/mappings - just register a custom provider. I'm going to close this as won't fix...
        Hide
        Sergey Beryozkin added a comment -

        doing something like WebClient.create(address,
        Collections.singleton(new JacksonProvider())) will 'fix' it.

        Show
        Sergey Beryozkin added a comment - doing something like WebClient.create(address, Collections.singleton(new JacksonProvider())) will 'fix' it.
        Hide
        Shaun Elliott added a comment -

        Why not? As I've stated before, the Restlet library does it very elegantly therefore it is possible.

        Show
        Shaun Elliott added a comment - Why not? As I've stated before, the Restlet library does it very elegantly therefore it is possible.

          People

          • Assignee:
            Sergey Beryozkin
            Reporter:
            Shaun Elliott
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development