jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: First steps

From: Roberto Chinnici <roberto.chinnici_at_oracle.com>
Date: Thu, 03 Mar 2011 15:00:29 -0800

  Thanks for calling these out. They're both already in the system: (n)
is JAX_RS_SPEC-13 [1], (o) is JAX_RS_SPEC-32 [2].

[1] http://java.net/jira/browse/JAX_RS_SPEC-13
[2] http://java.net/jira/browse/JAX_RS_SPEC-32

On 3/3/11 12:29 PM, Bill Burke wrote:
> Also:
>
> n) a fromTemplate() method in UriBuilder, or just allow URI params
> within fromUri(String) statements.
>
> o) We need to change some very incorrect language in the spec
> regarding EJB integration that is wrong and breaks many applications,
> specifically:
>
> "If an ExceptionMapper for a EJBException or subclass is not included
> with an applicaiton then...JUST be treated as EJB application
> exceptions."
>
> An EJB "application exception" has specific meaning in that these
> types of exceptions don't cause an automatic transaction rollback. In
> EJB, RuntimeExceptions are automatically rolled back (and wrapped with
> EJBException) for example, JPA exceptions. EJB programmers expect
> this behavior. The language in the JAX-RS spec turns this upside
> down. Just change the language to remove the "treated as EJB
> application exceptions" part.
>
> I apologize for missing this in the 1.1 rev.
>
>
> On 3/3/11 3:00 PM, Bill Burke wrote:
>> j) interceptor model (client and server side used extensively by our
>> users)
>> k) Link header support (rfc 5988)
>> l) improved/finer-grain message body reader/writer matching algorithm.
>> Specifically sorting based on template parameter as well as what we
>> already sort on.
>> m) An exception hierarchy (client and server side) that is
>> ExceptionMapper friendly
>>
>>
>> IMO, we really need a), l), and m) as users are most effected by these
>> in my experience. Anything else is a bonus.
>>
>> I'm a bit worried about c) as I think JAXB needs a rev to better support
>> any hypemedia processing features that we want to add (i.e. pluggable
>> annotation processing/callbacks as well as a JSON mapping).
>>
>>
>>
>> On 3/3/11 2:29 PM, Roberto Chinnici wrote:
>>> Welcome to the public JAX-RS 2.0 EG mailing list!
>>>
>>> A couple of days ago I transferred the open issues from JSR-311 (aka
>>> JAX-RS 1.0) to the JIRA for this project [1]. I haven't changed the
>>> priorities except in one case, but it seems to me that there are a
>>> number of low-priority issues disguised as "major" ones.
>>>
>>> I'd like to use the issue tracker quite extensively, both to track the
>>> items we're working on and to make sure we handle input from the
>>> community in a consistent way.
>>>
>>> When setting up the java.net project, I also transferred the current
>>> API
>>> sources and the specification sources from JSR-311; they are checked
>>> into the git repository for this project (see [2]).
>>>
>>> Besides the issue tracker, the other major source of work items is the
>>> JSR itself [3].
>>> Here's a summary:
>>> a) a low-level client API using the builder pattern
>>> b) a higher-level, REST-friendly client API
>>> c) hypermedia
>>> d) MVC support
>>> e) validation, via integration with Bean Validation API
>>> f) JSR-330 and CDI integration
>>> g) asynchronous request processing model
>>> h) "qs" parameter for content negotiation
>>> i) ease of use, e.g. DRY
>>>
>>> We should start by prioritizing this list as well as the issues already
>>> in the tracker.
>>>
>>> I'd also like to discuss right away any changes we want to make to the
>>> goals/non-goals currently listed in the spec (sections 1.2, 1.3).
>>>
>>> --Roberto
>>>
>>> [1] http://java.net/jira/browse/JAX_RS_SPEC
>>> [2] http://java.net/projects/jax-rs-spec/sources/git/show
>>> [3] http://jcp.org/en/jsr/proposalDetails?id=339
>>>
>>
>