On Feb 15, 2008, at 7:23 AM, Paul Sandoz wrote:
>
> Stephan Koops wrote:
>> Hello,
>> *Visibility of resource methods and locators*
>> Are non public (sub) resource methods and sub resource locators
>> allowed?
>
> No. We need to clarify that in the spec.
>
OK.
>>
>> *_at_Path*
>> Are matrix parameters allowed in @Path? In some cases that makes
>> perhaps sense to enforce a given matrix parameter for a method, but
>> this may result in non-determinism, e.g.: two methods annotated
>> with "path;mp1=xx" and "path;mp2=xx" (both "path" are equal!) with
>> request: "path;mp1=xx;mp2=xx". I think it is good to forbid ";" and
>> also "?" and perhaps other reserved characters (except "/" of
>> course) in @Path.
>
> I agree with this. Also there may be no specific order to matrix
> parameters (just like query parameters) so if there were allowed in
> the @Path then a complex matching algorithm would be required.
>
+1.
>
>> *Provider for JAXBElement*
>> I see a problem for implementing the provider for JAXBElement: I
>> think the proider can not know to which class it should convert the
>> given representation, because the generic type info with the class
>> to convert to is not available in the MessageBodyReader. If
>> readFrom(....) will not get only the the
>> javaMethod.getParameterTypes()[n] as type, but the
>> javaMethod.getGenericParameterType()[n], than the provider can read
>> it.
>
> Yes. My preference would be for the isReadable and readFrom methods
> to take the Class<?> and Type [*]. This would also solve reading
> Collection<MyType> as well.
>
So you'd have:
public interface MessageBodyReader<T> {
boolean isReadable(Class<?> type, Type genericType);
T readFrom(Class<T> type, Type genericType, MediaType mediaType,
MultivaluedMap<String, String> httpHeaders,
InputStream entityStream) throws IOException;
}
Where type=getParameterType()[i] and
genericType=getGenericParameterTypes()[i], where i is the index of the
parameter that is the entity ?
>> Must a MessageBodyWriter/MessageBodyReader close the input / output
>> stream? The Jersey providers does, but it is not requested in the
>> specification or in the javadoc.
>
> Can you point to some code? I looked at all the providers in the
> latest source and none of them close the InputStream or OutputStream
> instance that is passed respectively to the readFrom or writeTo
> methods.
>
> The intent was that the providers should not have to close or flush
> the stream and it would be the responsibility of the caller to do
> that, including guarding against potential unintended side-effects
> if the callee does close the stream.
>
I think we need to be explicit about this in the javadoc. What kind of
side-effects would you expect if the callee did close the stream. Do
we want "there's no need to close the stream" (implies you can but
don't need to) or a "you must not close the stream" (implies things
will break if you do).
>
>> Do you mean, every container must provide support for
>> javax.*xml*.transform.Source instead of javax.transform.Source?
>
> Yes, nice catch. I have not had time to implement these in Jersey yet.
>
OK.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.