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
> <mailto: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
>> <mailto: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
>>> <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> 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
>>>
>>
>>
>
>