Ah ha! It's all clear now. The Bookmark example application in Jersey
actually help clarify it all. I now get the big picture, thanks.
Ryan-
On 11/7/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Ryan McDonough wrote:
> > @Stateless
> > @UriTemplate("/people")
> > public class PeopleServiceBean {
> >
> > @GET("{id}")
> > public Person getPersonById(@UriParam("id") String id) {...
> >
> > This way the developer doesn't have to explicitly add another annotation
> > declaring that this resource must use the EJB lifecycle. This is a bit
> > more inline with how JAX-WS works.
> >
>
> Yes, for EE and SLSB there should be no need for another annotation. (It
> should be possible to hack ResourceProviderFactory implementation of
> Jersey to have this knowledge and get some prototype EJB integration
> going. The key missing piece is how to invoke the correct method of the
> EJB while conforming to the EE specification, this is where i am
> assuming WebBeans can help, in addition to providing EE like
> functionality without the requirement to be a SLSB.)
>
>
> > A per-request life-cycle model with constructors makes for a very
> > natural, simple and dry way to program resources (IIRC a per-request
> > life-cycle scope is the same for Rails, Django and Restlet). I have
> used
> > it many times to good effect in the Jersey examples, no need to
> worry
> > about state/threads, no need to repeat myself for common URI/Query
> > parameters, easy to check for existence of something and throw an
> 404
> > exception. IMHO it lowers the barrier of entry for efficiently and
> > correctly developing RESTful Web applications.
> >
> >
> > You lost me with the 404 example and query params example :) I don't see
> > how an EJB3 would be any different? Perhaps my head with some the this
> > is still working with the idea of exposing Java methods to return
> > different representations rather than in terms of the resource itself.
> >
>
> @Path("{id}")
> class Resource {
>
> // Each method has safe access to this field
> String id;
>
> Resource(@UriParam("id) String id) {
> // There is no need for all methods to have a
> // parameter annotated with UriParam
> this.id = id;
>
> // There is no need for all the methods to check
> // if id exists
> if (!exists(id)) {
> throw new WebApplicationException(404);
> }
> }
>
> @Path("furtherid")
> AnotherResource subLocator(@UriParam ...) { ... }
>
> @ProduceMime("application/csv")
> @GET
> String getCsv() { ... }
>
> @ProduceMime("application/atom+xml")
> @GET
> String getAtom() { ... }
>
> @PUT
> String put(...) { ... }
>
> @DELETE
> void delete() { ... }
>
> }
>
> Now, i am sure you can do some of this using EJB post constructors or
> interceptors which is fine, BUT, the learning curve is higher for those
> non-EJB developers than just using plain old Java language concepts with
> per-request scope. This concept also integrates very nicely with other
> JVM-based languages, like Scala, that have a short cut syntax for
> constructors, where constructor parameters are fields, so i can write a
> Scala-based resource as follows:
>
> @UriTemplate("({lx},{ly}),({ux},{uy})")
> class MandelService(
> @UriParam("lx") lx: double,
> @UriParam("ly") ly: double,
> @UriParam("ux") ux: double,
> @UriParam("uy") uy: double,
> @DefaultValue("512") @QueryParam("imageSize") imageSize: int,
> @DefaultValue("512") @QueryParam("limit") limit: int,
> @DefaultValue("8") @QueryParam("workers") workers: int) {
>
> ...
> }
>
> Paul.
>
> --
> | ? + ? = 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
>
>
--
Ryan J. McDonough
http://www.damnhandy.com