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

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 11 Oct 2007 09:47:42 -0400

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 ?


> On 10/10/07, Marc Hadley <> 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]
>> [2]
>> new_jersey_feat.html
>> [3]
>> 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:
>>> 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.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Ryan J. McDonough

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