I don't think there is any way to get 'stop' notification within JAX-RS.
Perhaps it is possible to do in a Jersey specific way using HK2 (but then
you would depend on Jersey/HK2 instead of Servlet API).
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