Hi Stephan,
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.
> The meaning of visibilty limitation is to not allow access from
> everywhere. I think, this should retained here, that means that only
> public (sub) resource methods and sub resource locators are allowed. Or
> is there any advantage to allow also non-public methods here?
>
> *_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.
Incidentally the RI has a mode to switch of matrix parameter processing
if one really wants to use ';' in a @Path.
> *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.
> *Providers in general*
> Why did we need the annotation @Provider? Does it is not enough to
> implement the interface(s) MessageBodyReader and/or MessageBodyWriter?
What happens if a concrete class implements those interfaces but the
intention is that they should not be exposed? The declaration of
@Provider makes it very explicit on the intent that the concrete class
is a component managed by the JAX-RS runtime.
> The Jersey providers are also not annotated with @Provider.
>
This is because i wanted:
1) Application specific readers/writers to take precedence over Jersey
readers/writers; and
2) Specify an ordering for Jersey readers/writers.
So i am using META-INF/services for Jersey readers/writers to support
the above. However, relevant examples in the Jersey distribution do use
@Provider.
> 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.
> 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.
Paul.
[*] I wish in Java one could do this:
ParameterizedType t = JAXBElement<MyType>.type;
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109