Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.1
    • Fix Version/s: 1.0
    • Component/s: Server
    • Labels:
      None

      Description

      Just to discuss how should empty incoming body content be handled for each MessageBodyReader? Should be consistent across all readers.

        Activity

        Bryant Luk created issue -
        Hide
        Nick Gallardo added a comment -

        Looks like the consensus in JAX-RS 1.1 was to return a null object. The change in 1.1 is that for all providers except JAXB, the result should be a null object return. In the case of JAXB, I believe the return should return a 400.

        See: https://jsr311.dev.java.net/issues/show_bug.cgi?id=55

        Show
        Nick Gallardo added a comment - Looks like the consensus in JAX-RS 1.1 was to return a null object. The change in 1.1 is that for all providers except JAXB, the result should be a null object return. In the case of JAXB, I believe the return should return a 400. See: https://jsr311.dev.java.net/issues/show_bug.cgi?id=55
        Hide
        Bryant Luk added a comment -

        Maybe I'm misreading, but I don't think that's what the bug says.

        For instance, empty incoming body for String would be "" and not null.

        Show
        Bryant Luk added a comment - Maybe I'm misreading, but I don't think that's what the bug says. For instance, empty incoming body for String would be "" and not null.
        Bryant Luk made changes -
        Field Original Value New Value
        Assignee Bryant Luk [ bluk ]
        Hide
        Bryant Luk added a comment -

        I'll write the remaining tests for the standard message body readers to make sure we keep behavior consistent. Looking at it now, I think most if not all of the readers follow JAX-RS 1.1.

        Show
        Bryant Luk added a comment - I'll write the remaining tests for the standard message body readers to make sure we keep behavior consistent. Looking at it now, I think most if not all of the readers follow JAX-RS 1.1.
        Hide
        Nick Gallardo added a comment -

        Ah, so I guess I see it a little differently. To me "empty incoming body" means Content-Length == 0. So, there's no content in the stream and the MessageBodyReader should represent that in a non-null object form.

        To your point of MessageBodyReader<String>, that would be just

        if (contentLength == 0)
            return new String();
        

        Here's what was added to 1.1:

        "See Issue 55. Clarify handling of empty message bodies for standard message body readers. All bar JAXB will result in an empty (not null) object being passed to the resource method. Using the JAXB entity provider will result in a 400 client error. Add description of how to override default behavior using a custom provider."

        Show
        Nick Gallardo added a comment - Ah, so I guess I see it a little differently. To me "empty incoming body" means Content-Length == 0. So, there's no content in the stream and the MessageBodyReader should represent that in a non-null object form. To your point of MessageBodyReader<String>, that would be just if (contentLength == 0) return new String (); Here's what was added to 1.1: "See Issue 55. Clarify handling of empty message bodies for standard message body readers. All bar JAXB will result in an empty (not null) object being passed to the resource method. Using the JAXB entity provider will result in a 400 client error. Add description of how to override default behavior using a custom provider."
        Hide
        Hudson added a comment -

        Integrated in Wink-Trunk-JDK1.5 #135 (See http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/135/)
        Add integration tests for empty body content

        See []

        Show
        Hudson added a comment - Integrated in Wink-Trunk-JDK1.5 #135 (See http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/135/ ) Add integration tests for empty body content See []
        Bryant Luk made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 0.2 [ 12314064 ]
        Resolution Fixed [ 1 ]
        Bryant Luk made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Bryant Luk
            Reporter:
            Bryant Luk
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development