It seems to be possible to get 'stop' notifications
with ApplicationEventListener in Jersey:
https://jersey.java.net/documentation/latest/monitoring_tracing.html#d0e14121
On Thu, Sep 11, 2014 at 4:56 PM, Mikael Ståldal <
mikael.staldal_at_appearnetworks.com> wrote:
> 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
>
--
Mikael Ståldal
Chief Software Architect
*Appear*
Phone: +46 8 545 91 572
Email: mikael.staldal_at_appearnetworks.com