Hi,
I'm not a spec lead, but here are some personal opinions to some of your
comments. I've inlined them.
@All: comment or correct, if something is wrong etc.
@Sean: If you are not a member of the mailing list
users_at_jsr311.dev.java.net, join the list to get all answers. (see
https://jsr311.dev.java.net/servlets/ProjectMailingListList; you must
have an account on java.net)
> Configuration through ApplicationConfig
> Is there any way to tighten up the getResourceClasses() and
> getProviderClasses() to return something more specfic than sets of
> <Class<?>>?
>
What do you mean here? Because the providers and root resource classes
are POJOs, it's not required, that they implement any interface or
subclass any class. Can you give a proposal?
> On page 5, line 23, I think it is a bad idea to depend on another spec
> to define how something fundamental as publishing a Provider in Java
> SE is done. That said, I am unfamiliar with JAX-WS. Personally, I
> think Spec interdependencies are dangerous and should be avoided in
> general. If this spec takes the position of leveraging JAX-WS then
> there should be an up-front section explaining where and why this is
> done.
>
In my undestanding no runtime enviroment is required to support JAX-WS.
The implementation on top of Restlet (www.restlet.org) do also not
support JAX-WS providers, and will throw an
UnsupportedOperationException for a call of
RuntimeDelegate.createEndpoint(..).
IMO the full section 2.2 describe some possible default ways. Only if a
concrete runtime enviroment should support JAX-WS, than it must support
this way.
> Page 10, line 13, what does "closest matching provider" mean? How is
> closeness determined?
>
The closest in the exception class hierarchy. Sean, you are right: A
link to section 4.5 is useful here.
> Page 10, line 30, what is the "declared metadata?" Seems like this
> should be more clearly specified.
>
The metadata are the http headers. You are right: This is not clear in
the full spec and also in the API. Perhaps we could rename
Response.getMetadata() to getHeaders() and so on.
> Page 12, line 8. What would happen if @ProduceMime("text/html")
> decorated the getWidget method. It seems like there should be an
> error.
>
I think, you mean page 13, line 8. If there is a custom entity provider
to convert a Widget to text/html, than it is no problem; otherwise you
are right. But you are also right, the example is a little bit
inconsistent according to the media types.
> Page 15, footnote. I suggest using a less esoteric wording. I have no
> idea what an "Explicitly platonic method" is. Does it mean that I have
> declared that I love it in a non-sexual way?
>
> Are there other forms of content negotiation supported other than URI-based?
>
There are also the default http capabilities (headers "Accept*").
BTW: UriInfo should change a little bit according to this, see
https://jsr311.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1277
> Page 19, line 21 & 22. I would prefer that constructors with the same
> number of parameters either not be allow or be undefined. This avoids
> unanticipated compatibility issues.
>
IMO the spec allows a little bit undefinition here. But we could also
change it.
> End of Chapter 5. There is a blank page.
>
All chapters start on an odd page number, so an empty page is inserted,
as before chapter 1.
best regards
Stephan