Hi,
some more comments:
*Providers*
* The idea for the MessageBodyWorkers is, that you can combine
multiple entity providers to a new entity provider (see spec).
Than we should think about to restrict the permission to close the
steam by MessageBodyReader.readFrom(......) (perhaps only allow if
end of stream is reached) and MessageBodyWriter.writeTo(......)
(IMO forbid ever or recommend to not close).
* IMO it is useful to change the parameter order in
MessageBodyWorkers methods to the same as the
MessageBodyReader/Writer, that means put the MediaType behind
Class and Type.
* What about require a provider for file upload by a browser
(MediaType "multipart/form-data")?
o If we support such provider, we should also add this media
type as static fields to the class MediaType.
*Annotations in root resource classes*
* Is a @Path with multiple vars with the same name allowed (e.g.
@Path("{p}/abc/{p}") )? IMO it is nonsense to requires this (as
app developer). The only case I see, is that the app developer
require, that both variables must have the same value (e.g.:
accept "1/abc/1", but not accept "1/abc/2"). This corresponds to
the back references of regular expressions. Some URI template [1]
implementations also do this way, I don't know if it is required
for them.
* What should happens with a @PathParam, for which is no variable
defined in the @Path? IMO it is useful to reject with status 500,
because IMO only @PathParams should be allowed to request from the
runtime, which are available. Should this be specified? (See also
next point.)
* It is specified, that @DefaultValue on a parametern (field, bean
setter) annotated with @PathParam is not allowed. What should a
runtime environment do, if a developer forget this restriction?
Warn? Reject? Should this be specified? The same question for
@Encoded on @HeaderParam and @CookieParam.
*Others*
* should be defined what a runtime envirnoment should do with
non-loadeable root resource classes and providers (e.g. no @Path
on a root resource class, invalid @Context fields, ...)? Reject
and not start fully? Warn and ignore? Let the runtime environment
decide this for itself?
* Marc, you added the enumeration Response.Status. You should also
add the constructors WebApplicationException(Status) and
WebApplicationException(Throwable, Status).
best regards
Stephan
[1]
http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.html