On Mar 29, 2010, at 3:29 PM, Florian Hehlen wrote:
> Ok… it’s working thanks.
>
> I have had to move some of the configuration that was happening in
> the web.xml into the spring application context(legacy stuff) and I
> needed to upgrade to 1.1.5.1 from 1.1.4.1… but it’s all starting to
> look good. I still have some issues with file-system resource
> discovery which somehow was much more easily done in the web.xml.
> This though is no longer a jersey/jax-rs issue.
>
> One of the issue I had is that the online links(at least some of
> them) at jersey.dev.java.net have not been updated to point to the
> 1.1.5.1 examples. So I was landing on some old examples.
>
Does the issue of old links still persist?
Paul.
> I am using Grizzly in my setup and I am able to programmatically
> reproduce my production web.xml which is good… maybe a bit slow(I
> also have some DbUnit initialization in the mix) but I will review
> that later.
>
> Cheers and thanks for the patients with my nagging questions.
>
> Florian Hehlen
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Thursday, March 25, 2010 11:46 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] simplest unit test bootstrapping
>
>
> On Mar 24, 2010, at 6:20 PM, Florian Hehlen wrote:
>
>
> 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.
>
>
> Where have you been looking?
>
> See the spring-annotations sample:
>
> http://download.java.net/maven/2/com/sun/jersey/samples/spring-annotations/1.1.5.1/spring-annotations-1.1.5.1-project.zip
>
> that uses Grizzly. Note that in this case no web.xml is utilized.
>
>
> It should be possible to use the embedded GF support with a web.xml
> as long as one uses a maven project, as the current support requires
> that things reside in the locations as that for war-based maven
> projects. Note that we are currently using an old version of GF
> embedded, we need to do this until we can switch over Jersey to
> using SE 6.
>
> If you can send me a zipped up version of your project i might be
> able to help more.
>
> Paul.
>
>
> 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.
>
>
> 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.