jax-rs-spec
  1. jax-rs-spec
  2. JAX_RS_SPEC-470

Clarify how default MessageBodyReaders should deal with concrete implementations of interfaces

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1
    • Component/s: spec
    • Labels:
      None

      Description

      We've had a user reporting an issue to do with CXF javax.activation.DataSource provider throwing an exception after a user typed 'javax.activation.FileDataSource' in the signature.

      Given that the spec requires support for java.io.File it was easy to provide a support for javax.activation.FileDataSource OOB.

      Now the user asks is it against the spec for a default provider to support a type not specifically mentioned in the spec.

      IMHO the spec should clarify what MessageBodyReader supporting the interfaces required to be supported by the spec should do when it sees a concrete, well-known interface implementation.

      Here are 3 proposed solutions:
      1. Recommend that "Default MessageBodyReaders may support some concrete implementations" - the problem here is that we may have a portability issue between the implementations
      2. Specify some of concrete implementations such as javax.activation.FileDataSource, and a couple of known JAXP Source classes.
      3. Request that if concrete implementation class is typed in the method signature and it is different from the class MessageBodyReader uses to support a given interface then throw 500.

      I think 3 may be reasonable - but may be we can relax it a bit with 2.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Santiago Pericas-Geertsen
            Reporter:
            beryozkin_sergey
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: