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