Hi Paul,
Thanks for the explanations. The usage of JAX-RS classes was not obvious
from browsing the API Javadocs. I still feel closer to the other more
annotation-driven approach, but I need to look at this more closely.
Best regards,
Jerome
> -----Message d'origine-----
> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Envoyé : jeudi 6 mars 2008 16:38
> À : dev_at_jsr311.dev.java.net
> Objet : Re: JSR311: Client API
>
> Jerome Louvel wrote:
> > Considering the initial scope of the JSR and the fact that
> the EG is already
> > behind schedule, I don't think it is reasonable to pursue
> such an effort for
> > now.
> >
>
> Makes sense. I agree with Marc that it could be something to consider
> for another revision rather than for this revision.
>
>
> > What surprises me is that the client-side API proposed has
> nothing to do
> > with annotations and don't even seem to reuse any artifact
> from the current
> > API.
> >
>
> The following classes are used:
>
> javax.ws.rs.core.Context
> javax.ws.rs.core.EntityTag
> javax.ws.rs.core.MediaType
> javax.ws.rs.core.MultivaluedMap
> javax.ws.rs.ext.MessageBodyWriter
> javax.ws.rs.ext.MessageBodyReader
> javax.ws.rs.ext.RuntimeDelegate
> javax.ws.rs.ext.RuntimeDelegate.HeaderDelegate
> javax.ws.rs.core.UriBuilder
>
> From a design perspective it:
>
> - follows the same ease of use pattern for building requests as on the
> server side for build responses; and
>
> - uses the message body readers/writers with injectable
> configuration as
> can be done on the server side.
>
> The main focus of the API is the uniform interface (it can be
> considered
> a very simple wrapper over say HttpURLConnection or the Apache HTTP
> client). I wanted to avoid the reliance on any specific code
> artifacts
> specifying, or partially specifying, a service that introduces static
> dependencies in code thereby increasing the coupling between
> client and
> server. From the way i approached the problem it did not make
> any sense
> to reuse the annotations for the client side.
>
> I also want a (pre-configured) client-side artifact i could
> inject and
> reuse on the server-side, like as follows (without having to
> create or
> depend on any server-specific code artifacts):
>
> @Path("/")
> public class Foo {
> @WebResourceRef("http://host/path") WebResource r;
>
> @GET public String get() {
> return r.get(String.class);
> }
> }
>
> Paul.
>
> > What is the point? If we have to do something within JAX-RS
> (now or later),
> > it would make much more sense to follow the approach
> proposed by Bill.
> >
> > Best regards,
> > Jerome Louvel
> > --
> > Noelios Consulting
> > http://www.noelios.com
> >
> >> -----Message d'origine-----
> >> De : Bill Burke [mailto:bburke_at_redhat.com]
> >> Envoyé : mercredi 5 mars 2008 21:09
> >> À : dev_at_jsr311.dev.java.net
> >> Objet : Re: JSR311: Client API
> >>
> >>
> >>
> >> Marc Hadley wrote:
> >>> Issue 22[1] raises the question about whether we should
> >> define a client
> >>> API as part of JAX-RS. Back in October[2] we tabled
> >> discussion until
> >>> we'd made some progress on a client API we were developing
> >> for testing
> >>> purposes. Paul recently blogged about the resulting API
> >> that has been
> >>> developed in Jersey[3] and I'd like to revive the
> >> discussion on issue 22
> >>> now we have something concrete to propose. For reference
> I've also
> >>> uploaded the javadoc[4] to the jsr311 project.
> >>>
> >>> The API is implemented in Jersey trunk and will be included
> >> in Friday's
> >>> release of the 0.6 snapshot. I'd recommend getting a copy
> >> and playing
> >>> with the classes a little to get a feel for how things slot
> >> together.
> >>> Paul will follow up tomorrow with some additional worked examples.
> >>>
> >>> Note that a client API was not one of our original
> >> deliverables and is
> >>> only being discussed in light of requests from EG
> members. It would
> >>> still be an acceptable outcome (for me at least) to defer
> >> inclusion of a
> >>> client API to a subsequent revision of the specification.
> >>>
> >> I'm happy with Apache HttpClient and use it to test our jax-rs
> >> implementation. Its a little clunkier than what you're
> >> proposing, but a
> >> bit more mature and much more feature rich.
> >>
> >>
> >> For a client API I was thinking more of:
> >>
> >> http://wiki.jboss.org/wiki/Wiki.jsp?page=RESTeasyClientFramework
> >>
> >> Where you could re-use jax-rs annotations and providers on an
> >> interface
> >> to create a proxy. What we have implemented still needs some
> >> work, but
> >> you probably get the gist.
> >>
> >> Bill
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>