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

[jsr339-experts] Re: First steps

From: Roberto Chinnici <roberto.chinnici_at_oracle.com>
Date: Wed, 09 Mar 2011 10:47:23 -0800

  On 3/9/11 10:43 AM, Guilherme Silveira wrote:
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Wed, Mar 9, 2011 at 3:17 PM, Roberto Chinnici
> <roberto.chinnici_at_oracle.com> wrote:
>> On 3/8/11 9:48 AM, Guilherme Silveira wrote:
>>> Hi there,
>>>
>>>>> c) hypermedia => JAX_RS_SPEC-52
>>>>> d) MVC support => JAX_RS_SPEC-53
>>> Should we add details and questions soon, while
>>> discussing/implementing each one of those?
>> Sure, if it helps clarify the issue, you can add comments in JIRA.
>>
>>>>> i) ease of use, e.g. DRY
>>> Support defaults everywhere configuration is required, by supporting a
>>> default configuration (and allowing all defaults to be configurable).
>>> For instance, do not repeat json and xml serialization configuration
>>> in two places (i.e. let the framework know you do it just once).
>>> Other miscs related to dry:
>>> Avoid repeating URIs all over the place.
>>> Avoid using Strings for configuring reflection based information
>>> (thus, avoid annotations that receive Strings instead of types too)
>>>
>>> DRY is to not repeat what has been already mentioned, for example,
>>> what was just posted on pojo repeats the word pk 3 times, the word
>>> path twice. It repeats the notion of param when describing, well, a
>>> param. DRY would be to remove all those repetitions (from the entire
>>> resource schemas).
>> The repetition of "pk" in the example will become avoidable once the JDK
>> gives us access to method parameter names via reflection. We raised this
>> issue *many* times over the years and it looks like it should finally happen
>> in Java SE 8 (I know, two releases away...).
> @Path("something")
> @GET
> public Response something(...
>
> @Path("something")
> class SomethingResource {
> }
>
> Can we provide default configurations for the above ones?

Yes, we could.

--Roberto

> Regards
>
>> --Roberto
>>
>>> Regards
>>>
>>> Guilherme Silveira
>>> Caelum | Ensino e Inovação
>>> http://www.caelum.com.br/
>>>
>>>
>>>
>>> On Tue, Mar 8, 2011 at 2:18 PM, Markus KARG<markus_at_headcrashing.eu>
>>> wrote:
>>>> Sounds good, but shouldn't we have some kind of deadline for new items,
>>>> at
>>>> least a soft one? I mean, I'm a friend of fast progress, you know. ;-)
>>>>
>>>>> -----Original Message-----
>>>>> From: Roberto Chinnici [mailto:roberto.chinnici_at_oracle.com]
>>>>> Sent: Dienstag, 8. März 2011 00:00
>>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>>> Subject: [jsr339-experts] Re: First steps
>>>>>
>>>>> I added issues for the following items listed in the JSR:
>>>>>
>>>>> a) a low-level client API using the builder pattern =>
>>>>> JAX_RS_SPEC-50
>>>>> b) a higher-level, REST-friendly client API => JAX_RS_SPEC-51
>>>>> c) hypermedia => JAX_RS_SPEC-52
>>>>> d) MVC support => JAX_RS_SPEC-53
>>>>> e) validation, via integration with Bean Validation API =>
>>>>> JAX_RS_SPEC-54
>>>>> f) JSR-330 and CDI integration => JAX_RS_SPEC-55
>>>>> g) asynchronous request processing model => JAX_RS_SPEC-56
>>>>> h) "qs" parameter for content negotiation => already present as
>>>>> JAX_RS_SPEC-1
>>>>>
>>>>> I skipped this one (too vague):
>>>>> i) ease of use, e.g. DRY
>>>>>
>>>>> Process-wise, we should certainly prioritize the issues. Considering
>>>>> that we're talking about a few dozen items (only), once the list is
>>>>> stable I'll go over them and propose new priority assignments. And
>>>>> before we do that, we need to discuss how to use the five priority
>>>>> levels the java.net JIRA gives us.
>>>>>
>>>>> Right now, I'm fine with people bringing up on the mailing list issues
>>>>> they've encountered (or their users have encountered), clarifying them
>>>>> and discussing how they relate to existing issues. We'll have to do
>>>>> that
>>>>> anyway and it's better if the issues filed in JIRA are as clear as
>>>>> possible.
>>>>>
>>>>> On 3/5/11 2:04 AM, Markus KARG wrote:
>>>>>> Following the traffic in this mailing list in the last week, I am a
>>>>> bit
>>>>>> unhappy with the fact that there are currently three sources for our
>>>>> agenda:
>>>>>> JIRA, JSR and Bill's several emails.
>>>>>>
>>>>>> So I want to suggest that first Roberto is adding really *all* items
>>>>>> (including those of the JSR, not only those from Bill's emails) into
>>>>> JIRA
>>>>>> and then organizes a way how we will come to a priority list in a
>>>>> democratic
>>>>>> way.
>>>>>>
>>>>>> I do not see any sense in discussing any topics before we have such a
>>>>>> *single* list, but I do see a lot of things to discuss in rather
>>>>> short time.
>>>>>> So we should organize our discussions and try to process each item
>>>>>> separately, sequentially, and I would like to ask Roberto to apply a
>>>>>> moderating discussion style in the mailing list to allow a
>>>>> professional
>>>>>> processing of *all* items step by step.
>>>>>>
>>>>>> Roberto, what do you think?
>>>>>>
>>>>>> Regards
>>>>>> Markus
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Roberto Chinnici [mailto:roberto.chinnici_at_oracle.com]
>>>>>>> Sent: Donnerstag, 3. März 2011 20:30
>>>>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>>>>> Subject: [jsr339-experts] First steps
>>>>>>>
>>>>>>> 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
>>>>
>>