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

[jsr339-experts] Re: First steps

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 03 Mar 2011 15:29:35 -0500

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com