Just took a look at ByteArraySerializer.java. Overall, looks good. My comments
below.
- Line 36: Is this a copy/paste error? The "class" parameter applies to Java
serialization, which isn't used by this class.
- Line 39: Seems like a Javadoc copy/paste error.
- Line 52: Could you use a BufferedInputStream instead?
- Line 62: Catch more specific checked exceptions; allow runtime exceptions to
propagate.
- Line 83: Might want to use a BufferedOutputStream here for performance.
- Line 85: Same as line 62 - catch more specific checked exceptions; allow
runtime exceptions to propagate.
- Line 95: Remove references to CLASS_PARAMETER - this parameter only applies
to serialized Java objects, not byte arrays.
Coding style:
- No space between type and array brackets (e.g. "byte[]" not "byte []")
- Don't align variable declarations; e.g. don't do this:
public static final String MIME_TYPE = "application/octet-stream";
public static final int BUFFER_SIZE = 4096;
do this:
public static final String MIME_TYPE = "application/octet-stream";
public static final int BUFFER_SIZE = 4096;
Greg
On Tuesday, May 26, 2009, at 09:28AM, "Sandro Martini"
<[email protected]> wrote:
>Hi Greg,
>
>> I think the encoding of any error messages should be left to the
>> application. Also, XML (as is used in SOAP faults) and JSON both seem a bit
>> heavy to put in a header. This is why I initially raised the question of
>> whether or not we should support a response body in the error case.
>I don't know if there is a size limit to header lines, so i agree with this.
>
>> I'm still inclined to restrict error messages to the response headers, at
>> least for now. We can always add support for the response body later, if the
>> need arises.
>>
>Ok, also for me this is right.
>
>Bye,
>Sandro
>
>
