JAX-RS is part of JavaEE, so servers like Glassfish bundle it alongside
Servlet support. I'm saying that if we were to copy implementation found
in the Servlet API to the JAX-RS API you'll end up with duplicated code.
Gili
On 11/09/2014 5:05 PM, Robert DiFalco wrote:
> Well, Jersey implements JAX-RS. Which servers are you referring to
> that implement JAX-RS? Now you've got me really confused.
>
> On Thu, Sep 11, 2014 at 12:29 PM, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>