I'm not talking about your code, I'm talking about the servers. You're
asking for servers to duplicate the code used in Servlets inside JAX-RS.
Again, the vast majority of servers implement JAX-RS on top of Servlets.
And the Servlet API is tiny.... way smaller than JAX-RS itself. So why
should all servers be forced to add extra overhead just because you
personally don't want to use the Servlet API? If you don't want to use
it, don't use it. If you want any of its functionality, use it. I don't
even see what the big deal is: Grizzly supports Servlet API. If you're
missing any feature in JAX-RS, just add that Grizzly plugin and you're done.
Gili
On 11/09/2014 2:53 PM, Robert DiFalco wrote:
> >> 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
> <mailto: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
>> <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
>>>>
>>>
>>>
>>
>>
>
>