On Mar 25, 2008, at 11:36 AM, Stephan Koops wrote:
>
> while implementing JAX-RS there are some new questions about it:
>
> name JAX-RS
> The name JAX-RS is not realy good, because the X stands for XML. But
> JAX-RS should not required XML, as also pointed out in the goals of
> spec (see section 1.2). What about JA-RS?
> I know that this questions comes late, but this mind comes not
> earlier.
>
We had a lot of discussion about both spec and package names. I'd
rather not re-open that matter.
> @Context on PathSegment?
> What about @Context also allowed on type PathSegment? I know that it
> is also possible by using UriInfo.getPathSegments() and then fetch
> the last, but this raises the useability. It should be the last
> parsed path segment:
> • On a resource method the PathSegment that was parsed while
> looking for the resource class (if it is a root resource class that
> from @Path of the class)
> • On a sub resource method or locator it is the one from @Path of
> the java method.
I think what we have with being able to use @PathParam with
PathSegment is already adequate.
>
> ".." in @Path
> Perhaps I've requested it again, but I found nothing about it in the
> spec neither in the javadoc of @Path: IMO ".." and perhaps "." at
> the start must not be allowed in @Path
>
I agree.
> avoid body conversion to entity if not needed
> The conversion of the entity by the entity provider may take time.
> To avoid unneeded conversions, it could be useful to add a method
> Request.getEntity(), which processes the entity not earlier before
> the method is called. If the entity is not needed (e.g. if a
> precondition fails or no concrete resource method could be found)
> the time for unnecessary conversion could be saved.
There are already ways to get round this I think. E.g. you do some
work in the constructor of a per-request resource class or use
InputStream and MessageBodyWorkers to manage the deserialization.
> What if @*Param value is not available?
This is described in the Javadoc for @DefaultValue. I didn't want to
repeat the same text in all the @*Param javadoc but I could move it
there if folks prefer.
>
> javadoc
> • The javadoc of @HeaderParam points out, that you have to use
> HttpHeaders interface. It is also possible to use List<?>. Or is
> this not specified yet, only discussed?
Its not yet documented, I'll add this in the next few days.
> • Typing error: section Resoources.ResourceMesthods.Parameters:
> first line of @MatrixParam, ...: "wth" must be "with"
OK.
> • Marc, IMO is it useful to change all @ (@Path and so on) in the
> javadoc to @ (HTML equivalent for @). Eclipse shows the javadoc
> of a method, class and so on, if you move the mouse on it. But
> because @see and so on starts with @, the parser thinks it is such
> an javadoc annotation, but the javadoc parser don't know what to do
> with @Path. So the text is broken there. If you want, I can change
> it and send it as a SVN patch.
OK, I can fix this with a quick search and replace.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.