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
> <mailto: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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','mikael.staldal_at_appearnetworks.com');>
>
>
>
>
> --
> Mikael Ståldal
> Chief Software Architect
> *Appear*
> Phone: +46 8 545 91 572
> Email: mikael.staldal_at_appearnetworks.com
> <javascript:_e(%7B%7D,'cvml','mikael.staldal_at_appearnetworks.com');>
>