Paul Sandoz wrote:
>
> On Nov 7, 2008, at 9:34 PM, American Jeff Bowden wrote:
>
>> Paul Sandoz wrote:
>>>
>>> On Nov 7, 2008, at 6:52 PM, American Jeff wrote:
>>>
>>>> After a lot of poking around I've come up with this function to create
>>>> an embedded Grizzly instance from an already instantiated Application
>>>> object:
>>>>
>>>> protected SelectorThread createGrizzly(URI u, Application app)
>>>> throws IllegalArgumentException, IOException {
>>>>
>>>> return GrizzlyServerFactory.create(u,
>>>> RuntimeDelegate.getInstance().createEndpoint(app, Adapter.class));
>>>>
>>>> }
>>>>
>>>>
>>>> I'm wondering if this is really the right way.
>>>
>>> Yes. But how about i add methods to GrizzlyServerFactory to do this:
>>>
>>> GrizzlyServerFactory.create(String uri, ResourceConfig rc);
>>>
>>> GrizzlyServerFactory.create(URI, u, ResourceConfig rc);
>>>
>>> (and add the same for the LW HTTP server) in 1.0.1 ?
>>
>> Turns out I was barking up the wrong tree anyway. What I wanted was to
>> control the call to WebApplication.initiate so I could pass in a
>> ComponentProvider but I confused WebApplication with Application
>> somewhere along the way. Now that I'm unconfused I've got this:
>>
>> protected SelectorThread createGrizzly(URI u, ResourceConfig rc,
>> ComponentProvider cp) throws IOException {
>>
>> WebApplication wa = WebApplicationFactory.createWebApplication();
>>
>> wa.initiate(new ApplicationAdapter(rc), cp);
>>
>
> You can use "rc" directly, no need to wrap.
OK. I was just copying internal Jersey code and didn't notice the
difference between Application and ResourceConfig
>
>
>> return GrizzlyServerFactory.create(u, new GrizzlyContainer(wa));
>>
>> }
>>
>> So perhaps you could add
>>
>> GrizzlyServerFactory.create(URI u, ResourceConfig rc,
>> ComponentProvider cp);
>>
>
> Will do.
>
> BTW the component provider interface has changed in 1.0.1-SNAPSHOT.
> See here [1] for its use with Spring. It should be simpler to use, and
> Jersey does not get in the way as it did before in terms of IoC
> life-cycle.
>
> I would be interested to know what you think and if it supports your
> requirements.
>
> I have tried to capture all the existing requirements that developers
> were using the old interface for:
>
> - Deferring to IoC frameworks like Spring/Guice;
>
> - Instantiated but Jersey managed; and
>
> - Proxied but Jersey instantiated and managed.
>
> I plan to JavaDoc it before the 1.0.1 release.
My requirements are to inject a data access interface into my web
resource classes in such a way that I can inject mock objects during
unit tests and objects connected to the database during normal
operation. Both of these require that my code can control the
construction and configuration of the objects to be injected using
information known locally to the test or the service class.