Mikael,
Can't you just inject HeaderParam or HttpHeaders to get the remote address?
You should be able to do it without anything jersey specific, just JAX-RS.
On Thu, Sep 11, 2014 at 9:50 AM, Mikael Ståldal <
mikael.staldal_at_appearnetworks.com> wrote:
> I am working on a real-world application which could avoid using the
> Servlet API if there were a way to obtain the remote IP address of a
> request. It uses some Jersey specific stuff though.
>
> It's not about completely replacing the Servlet API, Servlets are and will
> remain useful for low-level HTTP applications. But it would be nice if a
> few small missing parts (like remote IP address of a request) were added to
> Jersey and eventually JAX-RS so that you could use JAX-RS for high-level
> REST applications and not have to use both JAX-RS and Servlet at the same
> time.
>
> As you might be aware, some JVM based HTTP/REST frameworks strictly avoids
> the Servlet API and uses non-Servlet based HTTP servers. E.g. Play
> Framework, I think this is because the Servlet API not not well suited for
> the strictly asynchronous request processing model of Play Framework.
>
> BTW, there are SIP Servlets (
> http://docs.oracle.com/cd/E19355-01/820-3007/gfmpq/index.html), but it's
> questionable whether it is useful to share a common generic API for HTTP
> and SIP.
>
> On Thu, Sep 11, 2014 at 6:04 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> Same here. I don't know of a real-world application that uses JAX-RS
>> alone (nor do I think we should aim for such a goal). The servlet API does
>> a good job. I don't think we should try to reinvent the wheel here.
>>
>> JAX-RS will never replace the Servlet API because the latter is lower
>> level and not based on REST. I think there will always be a place for such
>> an API and we should provide high-level (REST-specific) functionality in
>> JAX-RS and stick to low-level (HTTP and non-HTTP) implementations for the
>> Servlet API. Speaking of which, I think the concept of a non-HTTP servlet
>> API is kind of silly (an example of where *that* API overreached). I am not
>> aware of any such implementations and yet the Servlet API forces us to cast
>> to HttpServletRequest every time.
>>
>> Gili
>>
>>
>> On 11/09/2014 6:06 AM, Mark Thornton 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
>