Re: JSR311: Public Review Results

From: Stephan Koops <>
Date: Tue, 03 Jun 2008 18:27:54 +0200


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
    * 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

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:
> 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:
> Marc.