I am all for this SPI idea.
Ryan-
On 10/11/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Oct 10, 2007, at 7:34 PM, Ryan McDonough wrote:
>
> > 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?
> >
> Right. The EJBResourceProvider would be responsible for creating
> instances of all classes annotated with @EJBResource and managing
> their lifecycle.
>
> > 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.
> >
> OK, any other opinions for or against ?
>
> Marc.
>
> >
> > 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
>
> ---
> 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