On Apr 3, 2008, at 4:36 AM, Stephan Koops wrote:
>
> 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).
Good point, I'll fix that.
> • 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.
OK.
> • What about require a provider for file upload by a browser
> (MediaType "multipart/form-data")?
> • If we support such provider, we should also add this media type
> as static fields to the class MediaType.
I think I'd rather not add this. Providers should be portable so we
can leave it to developers to write other interesting one like this.
> Annotations in root resource classes
> • Is a @Path with multiple vars with the same name allowed (e.g.
> @Path("{p}/abc/{p}") )?
Yes.
> 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.
While I agree its odd, I don't think we should restrict it this way.
Its possible to use the same name for a path parameter when using sub-
resource methods and locators, that's why we have MultivaluedMap for
the return type of UriInfo.getPathParameters. @PathParam gets the
latest value (lexically) for the parameter.
>
> • 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.)
I think you should get the default value, see 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?
Actually I think we should allow it for use when the resource was
reached via a path where the path param wasn't specified.
> The same question for @Encoded on @HeaderParam and @CookieParam.
Warn and ignore, I'll update the javadoc.
> 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?
Warn and ignore I'd think.
> • Marc, you added the enumeration Response.Status. You should also
> add the constructors WebApplicationException(Status) and
> WebApplicationException(Throwable, Status).
OK.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.