Issue 9 (was Re: EJB or MDB as a Resource implementation)

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 10 Oct 2007 11:36:27 -0400

I think this is related to issue 9[1]. We've now done some
experimentation in Jersey on pluggable resource providers and have an
SPI that might suitable. I wrote a blog entry[2] on this and also
about integrating Spring[3] using the new SPI. I'd be interested in
feedback on the Jersey APIs and whether EG members are interested or
opposed to incorporating this kind of SPI into the JSR ?

Having per-request as the default lifecycle doesn't preclude other
lifecycles but the JSR doesn't currently define how such lifecycles
could be requested/managed. If we add an SPI as suggested above then
we'd have a standard way to do this.



On Oct 9, 2007, at 5:40 PM, Ryan McDonough wrote:

> One of the goals I had been working on with RESTEasy was the
> ability to
> expose an EJB 3 Session Bean or an MDB as a RESTful end point. I
> have some
> fairly dated pages here:
> And here:
> These pages describe an early idea I had of how it might be
> implemented. For
> the most part, much of it worked and the MDB portion was extremely
> handy.
> One thing I had not fully worked out was how to handle resource
> injection of
> things like headers, request contexts, etc. I had been working with
> JBoss
> Seam to achieve some of this but never got around to finishing it.
> Since
> Paul brought up the topic of the JSR-299 (aka Web Beans), it
> reignited the
> idea. Being able to do something like this would make the development
> experience a bit more JAX-WS-like in that you could simply add a
> few more
> annotations to an EJB and have it exposed as both SOAP and REST
> style web
> services.
> Since I got involved a bit late in the game, I haven't fully
> grasped the
> design decision to have the resource class created and destroyed on
> each
> request, so there maybe something very important I am missing here.
> However,
> even this type of thing is not something the EG is interested in
> pursuing,
> would it be possible to consider a mechanism whereby another type of
> component could serve as a Resource? This way, it is left up to the
> implementor to provide the support but standard annotations would
> still be
> valid. Thoughts?
> Ryan-
> --
> Ryan J. McDonough

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.