On May 28, 2008, at 10:35 AM, Stephan Koops wrote:
>
> my thesis nears it's end. Is it possible to create a new stable
> version the next days or week, e.g. version 0.81 ? If it is official
> available with its code and spec file, I can easy refer to it.
I would recommend using the public review draft for this purpose as
its an "official" JCP milestone. I don't want to publish a new API
snapshot or specification draft until the public review period ends,
doing so could cause confusion about which version of the spec folks
are meant to be reviewing and make it harder to work out exactly what
text comments refer to etc.
>
> IMO it is useful to finalize the UriBuilder.extension(.) change
> (extension is appended to the path on build time, not while call of
> this method) for it.
>
That will be included in the resolution of the issue about distinct vs
platonic URIs in UriInfo, see:
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1277
I haven't received any negative feedback on this proposal so I plan to
make those changes once the public review period ends.
> What about the discussion about @PathParam (@PathParam(..)
> PathSegment and @PathParam(.., limited=false) List<String>)?
> I could also write that there is open discussion about this and
> could not present a final solution in my thesis. It's also a good
> solution, because it's easy ... :-)
>
Paul and I discussed this again this morning, I'm going to be sending
an email outlining all the options with pros and cons this week. Its a
tricky issue so I'd go with the "open discussion" strategy ;-).
> Did I remember right, that there where no functional change in the
> spec document since the public review (v0.8), only carifications,
> type error removals e.g.?
>
So far, yes. The biggest change is a rework of the request->resource
matching section to clarify it.
> And one discussion point: The method
> SecurityContext.getAuthenticationScheme() requires, that it returns
> the constants BASIC_AUTH, CLIENT_CERT_AUTH, DIGEST_AUTH or FORM_AUTH
> of interface SecurityContext, if this auth scheme is meant (for ==
> instead of equals() for speed reasons I think). This requires, that
> this method does the matching, which also needs some equal compares.
> So the speed advantage is away, and it costs perhaps more than less
> time. Because of that I propose to remove the requirement, that it
> must be one of the constants, only equal objects.
>
Hmm, I think we inherited this from the servlet spec:
http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getAuthType()
I don't have a strong opinion on this one, what do others think ?
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.