I enthusiastically use JAX-RS alone and I know of many people in polyglot
environments that do. In fact, I don't know WHY someone would want to pull
in all of that complexity and overhead if they are simply trying to provide
a light-weight and fast stateless REST server. JAX-RS, JPA, Grizzly, and
Jedis are pretty much all I need. It was a happy day for me when I removed
all dependencies on servlets.
On Thu, Sep 11, 2014 at 9:04 AM, 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
>>
>
>