users@jersey.java.net

[Jersey] Re: Best Library to Unit Test Jersey Restful Web Services?

From: Mikael Ståldal <mikael.staldal_at_appearnetworks.com>
Date: Thu, 11 Sep 2014 16:49:58 +0200

Ideally, remote address should be added to a new revision of JAX-RS.

But while waiting for that, it can be added to
org.glassfish.jersey.server.ContainerRequest
in Jersey. That would make sense, since one purpose of the Jersey project
is to try new features for future revisions of JAX-RS (right?).

On Thu, Sep 11, 2014 at 4:43 PM, Mark Thornton <mthornton_at_optrak.com> wrote:

> It really requires a revision of JAX-RS and as such is not merely an issue
> for Jersey developers.
>
> Do you know of a way to get 'stop' notification within JAX-RS?
>
> Regards,
> Mark
>
> On Thursday, 11 September 2014, Mikael Ståldal <
> mikael.staldal_at_appearnetworks.com> wrote:
>
>> There seems to be a JIRA issue for this:
>> https://java.net/jira/browse/JERSEY-473
>>
>> But it's four years old, so this does not seems to be prioritized by the
>> Jersey developers.
>>
>> On Thu, Sep 11, 2014 at 3:57 PM, Mark Thornton <mthornton_at_optrak.com>
>> wrote:
>>
>>> The remote address is my number one item. It need not be an IP address,
>>> just a label that identifies the source of the request that make sense to
>>> users/administrators. I use it for logging and summaries and other
>>> management. Knowing that one of our users is having trouble but being
>>> unable to identify them is not very helpful. Authentication is a partial
>>> alternative (you then know who but not where they are in network terms).
>>>
>>> I collect usage statistics with a servlet filter. That could probably be
>>> done with JAX-RS except for wanting the remote address. The only other
>>> servlet feature I use is ServletContextListener to manage the lifecycle of
>>> some objects. I may have missed something, but I was unable to get
>>> notification of the application stop from JAX-RS.
>>>
>>> Mark
>>>
>>>
>>> On Thursday, 11 September 2014, Mikael Ståldal <
>>> mikael.staldal_at_appearnetworks.com> wrote:
>>>
>>>> Then perhaps we should propose that JAX-RS and/or Jersey should be
>>>> improved to provide such information.
>>>>
>>>> What information are you missing?
>>>>
>>>> I am missing the remote IP address of a request -
>>>> ServletRequest.getRemoteAddr().
>>>>
>>>> On Thu, Sep 11, 2014 at 12:06 PM, Mark Thornton <mthornton_at_optrak.com>
>>>> wrote:
>>>>
>>>>> Unfortunately I seem to end up needing information which is not
>>>>> available in a pure JAX-RS application.
>>>>>
>>>>>
>>>>> On Thursday, 11 September 2014, Mikael Ståldal <
>>>>> mikael.staldal_at_appearnetworks.com> wrote:
>>>>>
>>>>>> The point of InMemoryTestContainer is to cover your JAX-RS bindings
>>>>>> with your tests.
>>>>>>
>>>>>> It is possible to build an JAX-RS application which does not directly
>>>>>> depend on the Servlet API.
>>>>>>
>>>>>> On Thu, Sep 11, 2014 at 12:08 AM, cowwoc <cowwoc_at_bbs.darktech.org>
>>>>>> wrote:
>>>>>>
>>>>>>> A few months ago I asked (but did not receive a convincing
>>>>>>> answer): Why bother using InMemoryTestContainer if you can't test anything
>>>>>>> related to servlets? I mean, why do you need a container at all? Why not
>>>>>>> dump this code into a standard Java SE project and run JUnit against it?
>>>>>>>
>>>>>>> Also, if this is what JerseyTest is meant for, they should have just
>>>>>>> made InMemoryTestContainer easier to use directly. No need to create an
>>>>>>> abstraction on top of a single container.
>>>>>>>
>>>>>>> Gili
>>>>>>>
>>>>>>>
>>>>>>> On 10/09/2014 4:00 AM, Mikael Ståldal wrote:
>>>>>>>
>>>>>>> If you use JerseyTest with InMemoryTestContainer, then you do not
>>>>>>> have a Servlet environment, so "configure anything about the mounted
>>>>>>> servlet" is not relevant. If you depend on Servlet specific stuff, this is
>>>>>>> not for you.
>>>>>>>
>>>>>>> Perhaps JeresyTest with something else than InMemoryTestContainer
>>>>>>> is less useful, but JerseyTest with InMemoryTestContainer is great for unit
>>>>>>> tests. Please keep it and don't listen to Gili.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 9, 2014 at 9:53 PM, cowwoc <cowwoc_at_bbs.darktech.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The problem was that you couldn't configure almost anything about
>>>>>>>> the mounted servlet. You couldn't set the context path, or the listening
>>>>>>>> port, or register an servlet listener. It was nonsense. On top of it,
>>>>>>>> Jersey 1.x allowed you to at least do some of these things (the
>>>>>>>> functionality was removed and re-added in Jersey 2).
>>>>>>>>
>>>>>>>> It is quite possible that the latest version of Jersey 2 finally
>>>>>>>> does this right, but by now we've all lost our patience and moved on.
>>>>>>>> Besides which (as I've mentioned before) I still don't see the benefit of
>>>>>>>> abstracting away the container... definitely not with the heavy design I
>>>>>>>> see going on in JerseyTest. Users can and should just do this themselves if
>>>>>>>> they need to (which is going to be rare).
>>>>>>>>
>>>>>>>> Gili
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/09/2014 12:25 PM, Robert DiFalco wrote:
>>>>>>>>
>>>>>>>> What's the issue with JerseyTest? I use it all the time with no
>>>>>>>> problems. I usually use it with embedded Grizzly but I've tried pretty much
>>>>>>>> every embedded server. Makes testing super simple. For my system I use a
>>>>>>>> single static JerseyTest since I don't need a unique configuration or clean
>>>>>>>> slate between each test. I just use the same ResourceConfig class I use
>>>>>>>> with my production server.
>>>>>>>>
>>>>>>>> Super simple and I don't need to remember or standup a test
>>>>>>>> server before running my unit tests. For your "newClient" and "target"
>>>>>>>> lines I just use a short cut to the static JerseyTest fixture's
>>>>>>>> #target(...) method.
>>>>>>>>
>>>>>>>> My favorite thing about it is that I can run a test with the
>>>>>>>> debugger and step through any hard to resolve server-side bugs. I just use
>>>>>>>> the same
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 9, 2014 at 7:30 AM, Aris Alexis <
>>>>>>>> aris.alexis.gia_at_gmail.com> wrote:
>>>>>>>>
>>>>>>>>> What I do is run the main application with Tomcat.
>>>>>>>>>
>>>>>>>>> For testing I use JUnit and Jetty embedded. I start it up before
>>>>>>>>> the testing and shut it down later.
>>>>>>>>>
>>>>>>>>> some maybe helpful hints:
>>>>>>>>>
>>>>>>>>> Client client =
>>>>>>>>> ClientBuilder.newClient().register(MoxyJsonFeature.class);
>>>>>>>>> Response response =
>>>>>>>>> client.target(hostname+"/users/"+otherUserId).request().header("Cookie",
>>>>>>>>> getSessionId()).get();
>>>>>>>>>
>>>>>>>>> assertEquals(Response.Status.OK.getStatusCode(),
>>>>>>>>> response.getStatus());
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Aris Giachnis
>>>>>>>>>
>>>>>>>>> On Thu, Sep 4, 2014 at 10:45 AM, Vetle Leinonen-Roeim <
>>>>>>>>> vetle_at_roeim.net> wrote:
>>>>>>>>>
>>>>>>>>>> On 04.09.14 04:09, Andre Perez wrote:
>>>>>>>>>>
>>>>>>>>>>> I am using JDK 1.7, Jersey 2.12, Tomcat 7, MongoDB and
>>>>>>>>>>> RestAssured
>>>>>>>>>>> <https://code.google.com/p/rest-assured/> to unit test my Rest
>>>>>>>>>>> calls...
>>>>>>>>>>> The issue is that RestAssured needs Tomcat to be running with
>>>>>>>>>>> my war file,
>>>>>>>>>>> in order, to work. Is there an embedded server or in-memory
>>>>>>>>>>> server along
>>>>>>>>>>> with a different unit testing framework which I can use to test
>>>>>>>>>>> my Restful
>>>>>>>>>>> Web Services (basically without be tightly coupled to an
>>>>>>>>>>> external server)?
>>>>>>>>>>> Would love to hear people's suggestions regarding best practices?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We have great experience using JerseyTest (
>>>>>>>>>> https://jersey.java.net/documentation/latest/test-framework.html).
>>>>>>>>>> The in-memory test container works great, and enables us to run tests in
>>>>>>>>>> paralell, and we replace beans in some tests when we need to.
>>>>>>>>>>
>>>>>>>>>> Our tests usually start a in-memory container with JerseyTest,
>>>>>>>>>> and then just do `jerseyTest.target(someUri).request() ...` to access the
>>>>>>>>>> server and perform our testing.
>>>>>>>>>>
>>>>>>>>>> If you need Tomcat, you can still use JerseyTest and just
>>>>>>>>>> configure it to use an external container (
>>>>>>>>>> https://jersey.java.net/documentation/latest/test-framework.html#d0e15742),
>>>>>>>>>> but I suppose you will lose some of the advantages - you most likely have
>>>>>>>>>> to create something to actually start Tomcat and deploy your WAR file.
>>>>>>>>>>
>>>>>>>>>> Good luck!
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Vetle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mikael Ståldal
>>>>>>> Chief Software Architect
>>>>>>> *Appear*
>>>>>>> Phone: +46 8 545 91 572
>>>>>>> Email: mikael.staldal_at_appearnetworks.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mikael Ståldal
>>>>>> Chief Software Architect
>>>>>> *Appear*
>>>>>> Phone: +46 8 545 91 572
>>>>>> Email: mikael.staldal_at_appearnetworks.com
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mikael Ståldal
>>>> Chief Software Architect
>>>> *Appear*
>>>> Phone: +46 8 545 91 572
>>>> Email: mikael.staldal_at_appearnetworks.com
>>>>
>>>
>>
>>
>> --
>> Mikael Ståldal
>> Chief Software Architect
>> *Appear*
>> Phone: +46 8 545 91 572
>> Email: mikael.staldal_at_appearnetworks.com
>>
>


-- 
Mikael Ståldal
Chief Software Architect
*Appear*
Phone: +46 8 545 91 572
Email: mikael.staldal_at_appearnetworks.com