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