Hi,
I agree with Bill, that you do a good work, Marc.
Some opinions (all IMO) to the open issues:
* issue 8 and 18: Do not require that a runtime understand XML
descriptors. But if XML descriptors should be supported, it is
good to have a well defined and easy way to convert all artefacts
to a XML descriptor. That means, use the same names and values for
the XML tags and attributes as in the annotations.
* Issue 10 and 19: integration in EJB sounds good, but should be a
SHOULD in this spec, because not every JAX-RS runtime env supports
EJBs.
* Issue 39: if NewCookie should not subclass Cookie for design
reasons, then NewCookie could contain the same 5 attributes and
it's getter. I see no advantage that NewCookie has a Cookie as
attribute. Another possibility is a common subclass with the
attributes of Cookie, or a common interface. The first reduces the
lines of code, and both allows to handle a NewCookie and a Cookie
together, if someone needs it. For equals(.) a NewCookie must
never be equal to a Cookie, also if all values are the same,
because noth classes have a little bit different semantics.
Perhaps we could add an equal method If there is a common abstract
class, their could be a method AbstractCookie.equals(Cookie,
boolean), which boolean parameter allows to indicate, if a Cookie
could be equal to a NewCookie or not.
* Issue 40: constructors and errors: Ignore constructors with
parameters the runtime env has no values and log a warning for
them, and then choose one of the others with the most parameters;
runtime dependent. We could require, that the runtime also logs a
warning about the last.
* Issue 41: Standard String Entity Provider for */*: Why not?
* Issue 42 (HttpHeaders.getLanguage() return Locale instead of
String) Why not? But: Could Locale support every given String? Or
do their construtcors could reject some values? It should not be,
that an invalid value blocks HttpHeaders.getLanguages() or a full
request. A solution could be to ignore invalid values.
best regards
Stephan
Marc Hadley schrieb:
> Yesterday was the final day of EC voting following public review. I'm
> pleased to report that we received 12 positive votes, 0 negative with
> no abstentions (3 EC members didn't vote). You can view the results here:
>
> http://jcp.org/en/jsr/results?id=4628
>
> The next stage in the process is Proposed Final Draft which we plan to
> be ready for by the end of July. Here's the list of open issues we'll
> need to close before then:
>
> https://jsr311.dev.java.net/issues/buglist.cgi?component=jsr311&subcomponent=www&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&version=current&email1=&emailtype1=exact&email2=&emailtype2=exact&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Issue+Number&Submit+query=Submit+query
>
>
> Marc.