Scala: I doubt that it is a particular JAX-RS topic but more a general question how to map Java APIs on Scala, so it might be better suited in some interoperability JSR?
From: Clint Combs [mailto:clint_at_ccombs.net]
Sent: Dienstag, 8. März 2011 19:51
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: First steps
Hi all,
From my perspective the most interesting and wide-open topics on the list are the proposals to define hyperlinking (c) and link header (k) support. This morning I gave a presentation to our development group that covered our experiences with JAX-RS on past projects and this is one of the topics that was of interest during our discussion. It seems that there are several good ideas of how to do this, but making it useful and meaningful to clients is another thing. I'm reading through the current work to come up-to-speed on what's already being considered.
Another area of interest to me is alternative language support. Obviously, by making the APIs available in Java we're making it available to other languages on the JVM w/o any additional work. I'm personally doing more work with Scala these days, so I'm looking for ways to use the JAX-RS APIs in a way that is natural in that language. It's already quite straightforward but improved integration will likely involve some wrappers and implicit conversions in Scala. While I wouldn't expect that we'd be addressing specific integrations for many languages I would hope that we'll be open to consider how certain features map to and from various languages and smooth these integrations when it's possible or easy.
Clint Combs
clint_at_ccombs.net
On Tue, Mar 8, 2011 at 12:48 PM, Guilherme Silveira <guilherme.silveira_at_caelum.com.br> 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?
>> 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).
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
>> >
>
>
>