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.