Stephan Koops wrote:
> Hi,
>
> I'm not a spec lead, but here are some personal opinions to some of your
> comments.
Thanks! your comments/feedback on this (and in general) are very useful.
I hope i did not come across as inclusive in my reply, that was not the
intent: comments from and comments from comments from implementors,
users, spec readers, and EG members and spec-leads are all valuable.
Paul.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109