Marc Hadley wrote:
> 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?
>>
> That was issue 9:
>
> https://jsr311.dev.java.net/issues/show_bug.cgi?id=9
>
>>
>>> 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.
>>
> But that would only work for singletons. You'd still need to integrate
> the IoC framework into the JAX-RS runtime to support per-request
> resources and if you are going to do that the singleton support would be
> there anyway so those methods would be redundant.
>
It would be cool to figure out a standard SPI for this. Are you game?
We have one in RESTEasy, but it probably needs refinement, I'll post it
if you want.
BTW, I think the APIs would be similar, but not redundant. For
instance, in RESTEasy, for ease-of-use, we have separate registration
methods that supports per-request, singleton, JNDI references, and the
SPI I talked about above. What I'm saying is that these use-case
specific methods are still useful when and if an SPI for this is
defined. There's no point in forcing the user to use an SPI abstraction
for per-request or singleton when passing object or class references
around is simpler and less code.
>> 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.
>>
>> In all the above cases, users are going to struggle with portability
>> unless something is defined by the specification.
>>
> I agree we're going to need to do that for EE 6 but, given the differing
> timelines, I think we're going to have to defer some of those questions
> until after 1.0. For now I want to avoid specifying anything that is
> going to make the integration harder when we do it.
>
Ok, yeah, I see your point. We do have customers that want this stuff
finished/finalized yesterday rather than months(years?) from now.
Can we get a new spec revision released at EE 6 timeframe to fill in the
EE integration holes?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com