users@jersey.java.net

Re: [Jersey] Re: Problems running Jersey test framework with Embedded Glassfish container

From: Mark Petrovic <mspetrovic_at_gmail.com>
Date: Mon, 6 Sep 2010 06:56:47 -0700

Thank you for the update, Pavel.

Mark

On Sep 6, 2010, at 1:02 AM, Pavel Bucek wrote:

> Hello Mark,
>
> sorry for late reply.
>
> Current state of this module (jersey-test-framework-embedded-glassfish) is that its not working (as you discovered it by yourself..).
>
> Jon is working on new version, which is using latest stable glassfish release (3.0). Unfortunately, API for embedded GF has changed, so it may take a while.. You can check what is done in a branch dedicated to this task: https://jersey.dev.java.net/svn/jersey/branches/jersey-test-framework-embedded-glassfish/. There is one sample which works with this version - helloworld-webapp (same branch).
>
> We have same problems as you encountered - package scanning doesn't seem to work correctly; we temporarily workarounded this by custom ResourceConfig class.
>
> Jon might have some update (cc).
>
> Regards,
> Pavel
>
> On 9/4/10 9:18 PM, Mark Petrovic wrote:
>> Dunno if I'm onto something or just going down a maddening rathole (prolly both), but ... more data:
>>
>> I can add a println in my servlet startup listener to determine the path to, say, WEB-INF/classes:
>>
>> real path to WEB-INF/classes: /Users/petrovic/proj/trunk/theproject/src/main/webapp/WEB-INF/classes
>>
>> It seems the Jersey servlet is being handed a context real root in which there are no class files whatsoever, a setup which is driven by the existence of a web.xml in src/main/webapp/WEB-INF in the createArchive() in the embedded GF container.
>>
>> > From what I can tell, whatever File is passed to ScatteredArchive as the web.xml file, the embedded container considers the context real root to be the parent of that web.xml File, which is not going to work.
>>
>>
>> On Sep 4, 2010, at 9:58 AM, Mark Petrovic wrote:
>>
>>> 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
>>>
>>>
>>
>> --
>> Mark Petrovic
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>


--
Mark Petrovic