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