>> Yes, you can do it, but the cost/benefit is terrible.
Huh? In what way? My code seems pretty simple and tiny. You need to be
specific.
On Thu, Sep 11, 2014 at 11:38 AM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Robert,
>
> There is a huuuuuuuuuuge world of a difference between a library/container
> that supports the Servlet API and one that supports all the bloat that is
> JavaEE. Asking to do REST without Servlets is like asking to do REST
> without the TCP stack (reimplementing TCP on top of the UDP stack). Yes,
> you can do it, but the cost/benefit is terrible.
>
> It might interest you to know that I'm also deploying Jersey without a
> container or WAR file. I use Jetty on top of an executable JAR file. You
> don't have to use servlets if you don't want to, but they get used under
> the hood.
>
> Gili
>
>
> On 11/09/2014 2:35 PM, Robert DiFalco wrote:
>
> Why should I be forced to use servlets if I just want to create a REST
> server with Java? I don't want a container (then figure out how to get
> around it and do container-less), I don't want a .war file, I don't need
> anything that servlets provide. I happily use Grizzly as a fast and light
> HTTP server and Jersey for creating a REST protocol on top of that. How is
> JAX-RS trying to replace servlets?
>
> On Thu, Sep 11, 2014 at 10:00 AM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>
>> Robert,
>>
>> As far as I'm aware, all server implementations (including Grizzly)
>> include a Servlet implementation. Granted, in the case of Grizzly it's part
>> of a plugin but for most servers this is built-in. Last I looked, the
>> Servlet API was actually quite lean (72 classes) so I don't understand what
>> all the fuss is about.
>>
>> <rant>
>> I'm not against replacing the Servlet API, but I have yet to be convinced
>> that JAX-RS is a better alternative than Servlet API. If anything, the
>> opposite seems to be true. I've had a very hard time getting my voice heard
>> with respect to Jersey2 and JAX-RS development. More often than not, the
>> team ignores legitimate concerns by tagging them with some future milestone
>> that never occurs.
>>
>> If we're going to replace the Servlet API, let's do so in a more open
>> fashion. Throwing lipstick on this pig (i.e. putting up code on Github and
>> saying you'll accept patches) does not make this open-source.
>> Fundamentally, this is still a closed-source project with a read-only view
>> to the outside world. Just look at what happened when the community
>> overwhelmingly asked for Jersey2 to support Guice (a regression, mind you,
>> relative to Jersey1). They sat on it for *years* and did nothing. That
>> didn't go unnoticed.
>> </rant>
>>
>> Gili
>>
>>
>> On 11/09/2014 12:41 PM, Robert DiFalco wrote:
>>
>> 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
>>>>
>>>
>>>
>>
>>
>
>