On Jun 9, 2008, at 4:19 PM, Bill Burke wrote:
>
>
> Marc Hadley wrote:
>> On Jun 9, 2008, at 12:47 PM, Bill Burke wrote:
>>>>> I noticed jersey has an @Singleton annotation. Can we just add
>>>>> this to the spec? Its something I want in my implementation as
>>>>> well.
>>>> Seems to me that component lifecycle annotations really belong
>>>> elsewhere and if we add them in this JSR then we'd be getting
>>>> into the IoC framework space.
>>>
>>> Yeah, you're right. Kinda contradicts my arguments against
>>> ContextResolver too.
>>>
>>> Can we get some support for singletons in ApplicationConfig then?
>>>
>>> List<Object> getResourceInstances();
>>> List<Object> getProviderInstances();
>>>
>>> I've already run into the need of having portable singletons.
>>>
>> You don't think that is also getting into the IoC framework space ?
>
> I'll answer this question with a question. With the current APIs/
> SPIs, how would you plug in Spring in a portable manner?
IIRC, a ways back there were some discussions around having an SPI
available whereby different life cycles could be introduced, but I
don't recall if that went anywhere? I see a few issues with the API
defining lifecycle annotations:
Like Marc pointed out, you can end up in IoC land
How many different lifecycle types should the spec define?
I can see something like @Singleton working out if the spec defines
only how the lifecycle should be defined, but leave the implementation
up to the provider. I'd also like to suggest that support of these
lifecycle annotations are optional.
>
>> If you are using Spring or WebBeans you'd want those to be in
>> charge of the lifecycle, not the application directly...
>
> With the above additions, you could write an ApplicationConfig class
> that loads a Spring/Guice context which does all the configuration
> of the resources and providers.
Agreed. I could see JAX-RS provider in Spring could treat @Singleton a
variant of @Service and manage it accordingly. However, the annotation
is there to use even if I'm not using Spring, but I could count on the
same behavior across implementations.
> For an EE 6 app-server, IMO, we should really figure out and define
> how Web Beans and EJBs *must* interact with JAX-RS in 1) a single
> vendor solution and 2) a thirdparty JAX-RS implementation plugged
> into an EE environment.
+1 I'd also like to have comfort in knowing that I could swap out
RESTEasy for Jersey and not have to make major code (ideally no code
changes) changes because each provider implements EJB integration
differently. However, this is where I think you start entering IoC
territory and potentially start doing some of the things that Web
Beans is trying to do.
> In all the above cases, users are going to struggle with portability
> unless something is defined by the specification.
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>