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.
Marc.
[1]
https://jsr311.dev.java.net/issues/show_bug.cgi?id=9
[2]
http://weblogs.java.net/blog/mhadley/archive/2007/09/
new_jersey_feat.html
[3]
http://weblogs.java.net/blog/mhadley/archive/2007/09/
integrating_jer.html
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:
>
> http://resteasy.damnhandy.com/session-bean-service.html
>
> And here:
>
> http://resteasy.damnhandy.com/message-driven-bean-service.html
>
> 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
> http://www.damnhandy.com
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.