>
> Multiple possible methods / root resource classes for one request
> in the algorithm for matching requests to resource methods, part 1e
> does not define what happens, when multiple root resource classes
> have the same @Path annotation. The same is in part 2 f/g and 3b/c.
> Is it implementation dependent, like the choose of the constructor,
> if there are more valid constructors (all parameters correct
> annotated and with the same no of parameters?) Or must the
> implementation generates error status 500?
> BTW: To the illustrated case you can say, that the developer should
> be more intelligent, but another tricky case with the same problem
> are two classes or methods annotated with @Path("abc/{var}") and
> @Path("{var}/def") called with URI "http://.../.../abc/def"
>
You raise a tricky issue, it seems to me that generating an error
would be the right thing to do. Unless someone has a better idea for
how to pick amongst the alternatives ?
> sort ascending / descending
> The part referred to in the last paragraph defines that the first
> method of E should be used. If E ist sorted ascending (I think it's
> the default for sorting), than it is the path with the fewest
> literal chars. I think it is more meaningful to choose the one with
> the most literal chars. Example: @Path("constantPath") and
> @Path("{variableName}"). When sorting ascending, than the second is
> choosen, already if the first is already possible, but the first of
> this both is more meaningful.
>
The intent was to sort descending such that the path with the most
literal character would be sorted first, I'll make that clearer in the
specification.
> Make username available
> The spec says nothing about user authentication. On a blog in
> somewhere I've read that the container should handle this. (I don't
> know which blog.)
> For some applications it is useful to know not only that the user is
> authenticated, but also know in the code which user is accessing,
> for example to return a user specific entity or a specific list (the
> users bank accounts, fo example). It is possible, but not a good
> design to load the username from the HttpHeaders, because there are
> multiple authentication methods which are allowed to define their
> own headers.
> What do you think about an annotation @AuthenticatedUser or
> @Username? It could be handled like @MatrixParam, @QueryParam,
> @PathParam and @HeaderParam, that means that the parameter class
> must have a one argument constructor of type String or a static
> method valueOf(String). If no user was given, the parameter could be
> set to null or the existence of @AuthenticatedUser may be a singnal
> to reject this request. Wrong auth data must be rejected by the
> implementation.
>
See issue 5:
https://jsr311.dev.java.net/issues/show_bug.cgi?id=5
The latest proposal for this is at:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=649
I need to chase our security expert for feedback but I think this
proposal looks like a good way to go.
> javadoc bug in PathSegment?
> In the javadoc of PathSegment (latest trunk version) is described,
> that all escaped octets are decoded. The interface method
> UriInfo.getPathSegment(boolean) allows to say if the result should
> be decoded or not. This seams to be a javadoc bug in PathSegment.
Good catch, I'll fix the javadoc by removing the escaping requirement
from PathSegment.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.