Hello,
*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"
*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.
*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.
*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.
best regards
Stephan Koops