On Mar 13, 2008, at 7:48 AM, Stephan Koops wrote:
>
> UriInfo.getAncestorResource*()
> • I think it is better to return the root resource class (and
> especially the URI) as last and not as first. Did anyone think, the
> root resource class should be at the beginning? I remember, that
> Marc said, he has no special preferences.
No special preference, it seems logical to list the resources in the
order you encounter them but I could live with the reverse. Is the
intent to make it easier to get the direct parent ?
> • I think it is good to add in the javadoc explicit, that the query
> is never returned.
OK. What about matrix parameters ? I currently think they should be
included but I'm open to arguments against.
>
> • Both Lists should or must be unmodifiable (add to javadoc)
OK.
>
> UriBuilder
> • build(int...)? I think it is useful to add
> UriBuilder.build(int...), because often IDs are used for the URI
> build, and they are often Integers (but never null). I know that we
> could add a lot of other methods here, but I think this is a common
> use case.
Hmmm. Rather than doing that how about changing build(String...) to
build(Object...) and requiring that Object.toString is used to get a
parameter value. Then we can take advantage of autoboxing to support
primitive types.
> • port(String)? If template variables should als be allowed for the
> port, than we need UriBuilder.port(String). I think it should only
> be possible to set a port (0 (or1?) until 65535 (=2**16-1) ) or one
> template variable and nothing else. To unset the explicit port null
> should be used. For uriBuilder.port("808{lastPortDigit}") or
> something like this there is only a very little number of use cases
> and will complicates the algorithm to check for validity.
I can't see port(String) being used much - do we really need it ?
>
> RuntimeDelegate
> • createEndpoint(..): I think it is useful to officialy allow the
> throwing of an UnsupportedOperationException, if the creation of an
> endpoint is supported for no class.
OK.
> • createUriBuilder(): I think it is useful to add also javadoc to
> RuntimeDelegate#createUriBuilder(), UriBuilder#isEncode() and
> UriBuilder#setEncode(.), that the encoding is turned on by default.
OK.
> Constructors of root resource classes and providers
> I think it is useful to define also in the spec, that only
> constructors are checked, if they are valid (as in resource methods
> and locators
>
I don't understand what you mean, can you explain more ?
> MessageBodyReader/Writer
> I found no specifcation, what should happens, if no feasible
> MessageBodyReader or Writer could be found. I think it is feasible,
> to return
> • status 415 (Unsupported Media Type [of request body]) if no
> MessageBodyReader was found, and
> • status 406 (Not Acceptable [because requested response media type
> is not supported]) if no MessageBodyWriter is found.
OK.
> Annotation Inheritance
> IMO it should be clearly defined, if an implementation check first
> the super classes or the implemented interfaces for annotations on
> methods. The current text preferes the superclass, but is a little
> bit spongy, IMO.
>
OK, I'll make that more explicit.
> JSR 250 dependency
> The common dependency to JSR 250 for resource classes is placed in
> the javadoc of @Path. In the specification it is only available in
> the note to Java EE container. I think it is useful to put this from
> the @Path javadoc to the specification file, perhaps into the
> section "Constructors" of chapter "Resources". I think it is also
> useful for the providers.
>
Agree on removing it from @Path. Some of the JSR 250 annotations only
really make sense in an EE context so we may want to confine mention
of those annotations to the EE section of the spec.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.