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