Hi,
I finally have time to get back to this!
So I have decided to go the suggested way and to use a light-weight embedded server to load everything. I have tried with Grizzly, Jetty, and embeddable Glassfish... I am not having much luck. A lot of the examples I have found are out of date and/or do not include the spring integration.
Is there a way to simply point the test environment to the web.xml and resources used in prod? In this web.xml I have all that is needed to start a spring-based jersey app.
Here is an extract from my web.xml
<!--Jersey Context-->
<servlet>
<servlet-name>MyRestApplication</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MyRestApplication</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>Jersey Spring Web Application</servlet-name>
<servlet-class>com.sun.jersey.spi.spring.container.servlet.SpringServlet</servlet-class>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
<param-value>
com.sun.jersey.api.container.filter.LoggingFilter;com.sun.jersey.api.container.filter.GZIPContentEncodingFilter
</param-value>
<!--<param-value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>-->
</init-param>
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>
com.sun.jersey.api.container.filter.LoggingFilter;com.sun.jersey.api.container.filter.GZIPContentEncodingFilter
</param-value>
<!--<param-value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>-->
</init-param>
<init-param>
<param-name>com.sun.jersey.spi.container.ResourceFilters</param-name>
<param-value>com.sag.ids.service.filters.FastInfoSetFilterFactory</param-value>
</init-param>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.sag.ids.service.jersey.IdsApplication</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
<param-value>com.sag.ids.service.jersey.UriExtensionsConfig</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.sag.ids</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Spring Web Application</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<!--Spring Context-->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:com/sag/ids/service/applicationContext.xml</param-value>
</context-param>
<context-param>
<param-name>spring.property.location</param-name>
<param-value>classpath:com/sag/ids/service/spring.properties</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
Cheers,
Florian
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Thursday, March 11, 2010 11:11 AM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] simplest unit test bootstrapping
On Mar 10, 2010, at 5:09 PM, Florian Hehlen wrote:
Hi,
Using Grizzly would be my first choice, but I am crippled by an environment where any testing dependencies will also end up in my production!
The other thing is that we are not using Hudson but good old fashion ant!
I think ant is an orthogonal issue. You can use ant with Hudson too and there are some very handy ant-based maven utilities if you need to integrate with a maven repo.
If I was using Grizzly would I be able to do tests like I suggested below?
No.
I think it is key to test that the URL binding is binding to the right methods. I have APIs with many many finder-methods that all return lists of a same entities. The key thing would be to have a single instance of a resource that I can access both by making direct method calls and restful calls.
Another key thing is that I would like to avoid having to use Spring in my unit tests. I would like to instantiate a Resource class, set it's dependencies by hand, and then wrap it in a jax-rs container.... Am I asking for to much?
Perhaps :-) I have seen other developers mock up resources, but i am not experienced in this mock up approach to help you, sorry :-(
One way you can make this easier is to always use constructor injection in your resource classes. Then it becomes much easier to pass in mocked objects to the constructor.
To be honest i do not see much advantage to mocking up stuff as to actually using the stuff with an embedded or in memory container. To steal a phrase from Rich Hickey (Clojure inventor) "Those mock objects, they are mocking you". The mocking seems to require a bunch of extra code where as if one configures things to say use an in-memory or embedded container in conjunction with the client API then you are testing the artifacts far more closely to as they are intended to be used.
Paul.
________________________________
The information in this e-mail is intended only for the person or entity to which it is addressed.
It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it.
If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments.
Messages and attachments are scanned for all known viruses. Always scan attachments before opening them.