users@jersey.java.net

Re: Problems running Jersey test framework with Embedded Glassfish container

From: Mark Petrovic <mspetrovic_at_gmail.com>
Date: Sat, 4 Sep 2010 09:58:36 -0700

I've spent a few hours reading the Jersey embedded GF container source, as well as source for ScatteredArchive from the 3.0-Prelude-Embedded-b14 build (wow, that was not easy to find) of embedded GF.

I'm sure I'm missing something but on the console when I run tests I see

Sep 4, 2010 6:50:32 AM com.sun.jersey.api.core.WebAppResourceConfig init
INFO: Scanning for root resource and provider classes in the Web app resource paths:
  /WEB-INF/lib
  /WEB-INF/classes
Sep 4, 2010 6:50:32 AM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.4-ea06 08/27/2010 02:42 PM'
...
[further down Jersey says it cannot find any resource classes --- same as stack trace below]

but in the Jersey embedded GF container source, I see ScatteredArchive in createArchive() assembling a war using

                    war = new ScatteredArchive(baseUri.getRawPath(),
                            new File(SRC_WEBAPP_PATH),
                            new File(SRC_WEBAPP_PATH + "/" + WEB_INF_PATH + "/" + WEB_XML),
                            Collections.singleton(new File(TARGET_CLASSES_PATH).toURI().toURL()));

where TARGET_CLASSES_PATH is hardcoded in the Jersey embedded GF container instance as "target/classes".

If you look at how maven generates this target/classes directory, you find that there is no target/classes/WEB-INF directory, which is what Jersey appears to be scanning on startup. The maven war plugin is the thing that builds targets/<appname>/WEB-INF, not the compiler plugin. And the war plugin does not run in the test phase.

This has to be a one-line fix somewhere, but at this point I'm stumped.

Anybody?


On Sep 3, 2010, at 4:46 PM, Mark Petrovic wrote:

> I'm trying to mimic the samples/bookstore unit test example in the Jersey distribution to affect unit testing of a servlet-based Jersey webapp. However, in my case, when the embedded container starts, it is not finding the Jersey resource classes that comprise my webapp.
>
> Using this artifact in my pom.xml:
>
> <dependency>
> <groupId>com.sun.jersey.jersey-test-framework</groupId>
> <artifactId>jersey-test-framework-embedded-glassfish</artifactId>
> <version>1.4-ea06</version>
> <scope>test</scope>
> </dependency>
>
>
> From the console where 'mvn test' is executed;
>
> ...
> Sep 3, 2010 4:40:34 PM org.apache.catalina.loader.WebappLoader setClassPath
> INFO: Unknown loader org.glassfish.internal.api.DelegatingClassLoader_at_57fcca7b class org.glassfish.internal.api.DelegatingClassLoader
> Sep 3, 2010 4:40:34 PM org.foo.server.AppContext <init>
> INFO: application root: ./platform
> Sep 3, 2010 4:40:34 PM com.sun.jersey.api.core.WebAppResourceConfig init
> INFO: Scanning for root resource and provider classes in the Web app resource paths:
> /WEB-INF/lib
> /WEB-INF/classes
> Sep 3, 2010 4:40:34 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
> INFO: Initiating Jersey application, version 'Jersey: 1.4-ea06 08/27/2010 02:42 PM'
> Sep 3, 2010 4:40:34 PM com.sun.jersey.server.impl.application.RootResourceUriRules <init>
> SEVERE: The ResourceConfig instance does not contain any root resource classes.
> Sep 3, 2010 4:40:34 PM org.apache.catalina.core.ApplicationContext log
> SEVERE: WebModule[/vzserver]StandardWrapper.Throwable
> com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
> at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:103)
> at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1183)
> at com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:163)
> at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:700)
> at com.sun.jersey.server.impl.application.WebApplicationImpl$12.f(WebApplicationImpl.java:697)
> at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:197)
> at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:697)
> at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:692)
> ...
>
> Here is my test class:
>
> public class TestIngest extends JerseyTest {
>
> public TestIngest() {
> super(new WebAppDescriptor.Builder("org.foo.resources")
> .contextPath("vzserver")
> .servletPath("services")
> .build());
> }
>
> @BeforeClass
> public static void setUpClass() throws Exception {
> System.setProperty(AppContext.APP_ROOT, ".");
> }
>
> @AfterClass
> public static void tearDownClass() throws Exception {
> }
>
> @Before
> public void setUp() throws Exception {
> super.setUp();
> }
>
> @After
> public void tearDown() throws Exception {
> super.tearDown();
> }
>
> @Test
> public void testIngest() {
> System.out.println("URI: " + resource().getURI());
>
> MultiPart multiPart = new MultiPart();
> ...
>
> ClientResponse response = resource().path("/blah/foo").type(MediaType.MULTIPART_FORM_DATA_TYPE).post(ClientResponse.class, multiPart);
> assertNotNull(response);
> }
> }
>
>
> Can anyone comment on why the resource classes are not being found. They are defined in package org.foo.resources, and it seems the WebAppDescriptor knows this.
>
>
>
> --
> Mark Petrovic
>
>


--
Mark Petrovic