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