I read your post a while back, but it didn't quite register the first tome
around. By defining an SPI it would be possible for an implementation to
define an @EJBResource meta-annotation along with EJBResourceProvider. This
would in turn allow an EJB to be used as a Resource?
The SPI you've defined for Jersey looks elegant enough that it would provide
the hooks I am looking for. I definitely be interested exploring this idea
further.
Ryan-
On 10/10/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> 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.
>
>
> ---------------------------------------------------------------------
> 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