users@jersey.java.net

Re: [Jersey] Problems with jersey-test-framework and Guice

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 25 Aug 2009 14:30:18 +0200

On Aug 25, 2009, at 1:56 PM, Naresh wrote:

> Hi,
>
> is your application a web application? If so, can you try with
> EmbeddedGlassFish. I hope it should work, if your web.xml defines
> the filters.
>
> bea wrote:
>> Hi everyone,
>>
>> I've been trying to use a IoC container with jersey-test-framework
>> in order to access a PersistenceManager / Factory within my tests.
>> I've found that, in order to use Google Guice, I need to create the
>> web container and add to it a filter, used for the IoC container
>> bootstrapping. I've been stuck with the problem for a couple of
>> days, using Grizzly as the lightweight container, but found that
>> the test framework may be missing something necessary to bootstrap
>> Guice.
>>
>> I've spotted a couple of changes that may help:
>>
>> Adding the possibility to the GrizzlyWebContainer class of the test-
>> framework
>> (com.sun.jersey.test.framework.impl.container.grizzly.web) to add a
>> filter (so we could add the GuiceFilter to the filter chain).
> The latest version (1.1.2-ea-SNAPSHOT)

Latest version in the trunk is now 1.1.3-ea-SNAPSHOT as we are in the
process of releasing 1.1.2-ea.


> has this option of adding a filter, but I realized that this filter
> class isn't being utilized. I shall try adding this support in the
> trunk, and let you know once done, then may be you could check if it
> works.
>

Perhaps it would be best to add a simple Guice sample to the Jersey
samples?

I suppose "servletPath" can be reused for "filterPath", in hindsight
we should have called that property "urlPattern".

An example web.xml can be found here:

   https://jersey.dev.java.net/nonav/apidocs/1.1.1-ea/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html


Some other things:

- The implementaton of GrizzlyWebTestContainer does not need to copy
the state from WebAppDescriptor
   and instead can just keep a reference to it.

- i think we can remove the required dependencies on certain HTTP
containers like GF embedded.
   We still could define certain profiles for certain container but we
can also explicitly document what dependencies
   are required for what container.

- We should try and move to the latest GF embedded before any
investigations w.r.t. JPA are started.

Paul.