Your opinion sought: Jetty or Tomcat?

[Bruce Johnson]

Hi everyone,

Hope you're enjoying 1.5.

The GWT team has started putting together a 1.6 roadmap, which we'll publish as soon as we have it nailed down. Two of the areas we want to work on for 1.6 are some improvements to hosted mode startup time and a friendlier output directory structure (something that looks more .war-like). 

As part of this effort, we've all but decided to switch the hosted mode embedded HTTP server from Tomcat to Jetty. Would this break you? (And if so, how mad would you be if we did it anyway?) We figure most people who really care about the web.xml and so on are already using "-noserver" to have full control over their server config.

Thanks,

Bruce

[Ponthiaux Eric]

Jetty is faster .

regards.

Bruce Johnson a écrit :

[mikeds...@gmail.com]

Hey Bruce,

Don't think it would break me and I'm all for more speed in starting
up hosted mode. Additional features you'd care to share? I'd be
thrilled if the "use a real browser in hosted mode" idea bubbled back
up....FWIW.

Later,

Shaffer

[Michael Vogt]

Hi Bruce.

> As part of this effort, we've all but decided to switch the hosted mode
> embedded HTTP server from Tomcat to Jetty. Would this break you? (And if so,
> how mad would you be if we did it anyway?) We figure most people who really
> care about the web.xml and so on are already using "-noserver" to have full
> control over their server config.
>

I personally would welcome Jetty. I'm using it as part of Grails right
now. It's fast and easy going.

Cheers,
Michael

[Tim]

jetty is awesome.

In their latest drop (6.1.12.rc2 and rc3) there is a new feature in
maven-jetty-plugin to reload jetty on keyboard events in console
rather than automatically - it's indispensable when java GWT code
lives in the same source tree as the server side java code (just in
different package). And generally, maven jetty plugin is way better
than Cargo stuff that's used for Tomcat.

Also, Jetty Continuations are just some much easier to work with than
Tomcat's Comet. No wonder they are including it into Servlet spec 3.0.

Nothing particularly wrong with Tomcat but I think it's just lagging
in terms of developer productivity features behind Jetty.

[Jason Morris]

I personally use Tomcat a lot more, mainly because it started as the reference
implementation (though I know it no longer technically holds that position). The
few times I've wanted to use Jetty I've had to switch back to Tomcat due to lack
of system admin knowledge (ie: the various admins I was working with didn't know
it).

That all said, I almost never use Hosted Mode, and system admins don't have to
deal with a development time engine. Tomcat does have much better IDE support
than Jetty, but since Hosted Mode is in charge of that, again it makes no real
difference. When I do run Hosted Mode it's with the -noserver option.

So my end opinion: I think the change is a good idea, since the additional speed
and lower memory load will encourage people trying out GWT for the first time.

[Fred Janon]

I use Tomcat for all our customer deployments and as a server to host the development. If Tomcat is used as the server for development, there are probably less chances that something would not work when deployed. I am not sure of how popular is Jetty for real deployments compared to Tomcat, but I have the feeling that Tomcat is ahead of Jetty. The startup time in development mode is not really important for me, considering that there are not that many cases where the server needs to be restarted. We don't use any specific feature to a particular server, so Comet or continuations are not in the balance. A few weeks ago I deployed successfully a GWT app on Tomcat on a Windows server in about 30 mins. It still took me about 1 day to do the same on Ubuntu, not because of GWT, but because of the way Tomcat is configured by default on Ubuntu. Since it was the same server from beginning to end, I had less to investigate. If it was another server engine, I would have doubts on many more configuration issues.

I am looking at the Widgets and the incubator and I wish a lot more work was done there. Lots of customers and developers have "ext" on their lips, I'd like to see more development in that area. The ScrollTable is hardly usable at the moment. And some comments have been there with no response http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable

=========================================

Comment by di.zhao, Oct 01, 2008

Hi, this is pretty nice widget. For those who is puzzled by the demo not working in Firefox. I would suggest you to download the latest source code and run it locally. The ScrollTable works nicely in both Firefox/Chrome & IE.

One question though, will column drag and drop be supported in the future?

Comment by Stephen....@paretopartners.com, Oct 07 (6 days ago)

Please can someone update the docs and example. This is a brilliant widget but in this state its almost unusable :(

==========================================

The more I use GWT and the more I love it, I think it's a brilliant idea and implementation (I still have to find a bug in it!), but my priorities are not in the server startup time.

In summary the current use of Tomcat is pretty good, why change and spend time and $$$ instead of spending time on other nice features? "If it ain't broken, why fix it?"

But if you are already all decided then...

Fred

[El Mentecato Mayor]

I think it is broken in the sense that it does take a lot of time to
get the app running when in development mode (and hosted mode), or at
least more time that I would like it to.

I would welcome Jetty if that improves the performance. I have nothing
specific to tomcat so far, so nothing should be broken. I actually use
Jetty to deploy and test the application quickly in web mode.

On Oct 14, 3:44 am, "Fred Janon" <fja...@gmail.com> wrote:
> I use Tomcat for all our customer deployments and as a server to host the
> development. If Tomcat is used as the server for development, there are
> probably less chances that something would not work when deployed. I am not
> sure of how popular is Jetty for real deployments compared to Tomcat, but I
> have the feeling that Tomcat is ahead of Jetty. The startup time in
> development mode is not really important for me, considering that there are
> not that many cases where the server needs to be restarted. We don't use any
> specific feature to a particular server, so Comet or continuations are not
> in the balance. A few weeks ago I deployed successfully a GWT app on Tomcat
> on a Windows server in about 30 mins. It still took me about 1 day to do the
> same on Ubuntu, not because of GWT, but because of the way Tomcat is
> configured by default on Ubuntu. Since it was the same server from beginning
> to end, I had less to investigate. If it was another server engine, I would
> have doubts on many more configuration issues.
>
> I am looking at the Widgets and the incubator and I wish a lot more work was
> done there. Lots of customers and developers have "ext" on their lips, I'd
> like to see more development in that area. The ScrollTable is hardly usable
> at the moment. And some comments have been there with no responsehttp://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable
>
> =========================================

> Comment by di.zhao <http://code.google.com/u/di.zhao/>, Oct 01, 2008

>
> Hi, this is pretty nice widget. For those who is puzzled by the demo not
> working in Firefox. I would suggest you to download the latest source code
> and run it locally. The

> ScrollTable<http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable>works

> nicely in both Firefox/Chrome & IE.
>
> One question though, will column drag and drop be supported in the future?

>   Comment by Stephen....@paretopartners.com<http://code.google.com/u/@VRFTQFdRDxdFWAJ1/>,

[jvanroekel]

We run Tomcat in production and on our desktops. I prefer to test with
the same system. Having said that, I appreciate the value of Jetty.
So, why can't we have both? Make it a config option.

[Ian Petersen]

I use -noserver so, for me, effort spent on switching from Tomcat to
Jetty is "wasted", but I wouldn't begrudge the team for satisfying
demand.

Ian

[Matt Bishop]

Jetty +1

I am all for anything that speeds up hosted mode development.

[Yegor]

Whichever lets you release out-of-process hosted mode (OOPHM)
sooner :)

(I am using -noserver option anyway)

Thanks,

Yegor

On Oct 13, 4:48 pm, "Bruce Johnson" <br...@google.com> wrote:

[Jason Essington]

Since creating a usable server side configuration in the embedded
servlet container is all but impossible for anything but the simplest
projects, I think that the choice of embedded server is a non-issue.

Since complicated configurations aren't really something you want to
address in the embedded server, my vote would be for the simplest,
fastest implementation that supports the simple case uses.

So, if Jetty starts faster and is lighter weight, then great, use it.

-jason

[Jason Essington]

It already is! have a look at -noserver

My project requires a full blown JEE container, not just a servlet
engine, so neither tomcat nor jetty would be enough. I have been using
-noserver since the beginning and it works great.

If the embedded server doesn't fit your needs (no matter what that
server ends up being) then it is no big deal to use whatever server
does work for you.

-jason

[walden]

+1 well said.

> > Bruce- Hide quoted text -
>
> - Show quoted text -

[Scooter]

I do extensive get development in Netbeans for GWT and very happy with
the current setup minus increasing the maxmemory variable every time I
restart Netbeans so I don't run out of memory when building the
application. If I debug the project, I run in the GWT browser and can
do incremental debug updates on code without restarting as long as
method signatures don't change so I rarely have issues with startup
time when debugging code. When I want to test in browser I simply run
the project and it launches in my default browser fairly quickly. To
do a clean build takes about 1 minute 20 seconds on a fairly fast box.
Changing one file and selecting debug which will build and launch
takes 1 minute 30 seconds where startup of gwt browser takes about 10
seconds. I would like to see faster incremental build times when
changing only one file. I work around this by debugging/fixing bugs
and doing incremental updates on the current debug session and test
the new code. This way I don't repeat all the application steps to get
to the same debug state to test the code changes. Netbeans does the
update and recalls the method with the same values prior to the
incremental update.

The main point is I have a very productive and working environment
where I have a war file automatically built by netbeans and couldn't
think of any way to make it easier and I do nothing to mess with the
xml for building and deploying. No problems with you making changes
but hopefully it doesn't break what already works well in netbeans. It
would be nice if incremental builds was faster.

Thanks

Scooter Willis

[kozura]

If it's faster, go for it, don't see how it can break hosted mode.

If a substantial amount of the hosted start-up time is actually the
server, one alternative might be to have a built-in way to start up
the server portion separately, and let it stay running while iterating
client code. I find the server code to generally be more amenable to
hot-swapping, while changes in client code often require a restart, so
if it didn't have to restart the server each time that would be a big
bonus. Of course I can currently set stuff up run the server
separately on my own, but having the ability built-in seems more along
the GWT philosophy of easy entry.

[Jim Alateras]

I use both so wouldn't be an issue. I do prefer jetty as an embedded
HTTP server.

cheers
</jima>

[Arthur Kalmenson]

If it makes hosted mode launch faster, go for it :)

--
Arthur Kalmenson

[Manuel Carrasco]

The most annoying issue with GWT is performance in development mode. I mean, compiling, startng hosted mode and running GWT Unit tests. So any action that improves these is welcome.

So my vote if for jetty

[matias_warrior]

I've been using -noserver since GWT 1.3

[Joshua Partogi]

Bruce,

If your objective is to embed it in GWT, then I would definitely
recommend Jetty.

Cheers

[Alex]

Switching to jetty would be fine we me and my colleagues as well. We
use -noserver for hosted mode and unit testing (with some hackery).

[gregor]

Hi all,

Opinion on this thread seems pretty much one way, but I currently know
little of Jetty.

1) Can anyone give a brief summary of why Jetty is "better" than
Tomcat?
2) Can I be reassured I won't run into unforeseen difficulties
deploying to JBoss?

regards
gregor

[John]

Manuel Carrasco wrote:

The most annoying issue with GWT is performance in development mode. I mean, compiling, startng hosted mode and running GWT Unit tests. So any action that improves these is welcome.

So my vote if for jetty

+1

[obesga]

If Jetty could get more configurable ( add jar files; bbdd
connections, etc.. ) would be a great improvment.
Simply using less memory and resources is a step ahead; +1 jetty

For Gregor: both Tomcat and Jetty comply the Java servlet spec, so
there are no expected problems on code if GWT swich from one to
another.

Oskar

[Flemming Boller]

Hi

+1 for Jetty

Thanks for a great UI toolkit!

/Flemming

[jan]

Bruce et all,

On behalf of the Jetty team, can I say that we're delighted to hear
the GWT team is considering using Jetty for hosted mode.

According to NetCraft statistics, Jetty has around 70-80% of the
market share of Tomcat for *visible* deployed servers. Of course,
as Jetty is embedded in numerous products, like Eclipse IDE and
Grails, then actually the number of Jetty installations out there is
muuuuuuch bigger :) And there are some very very large production
sites that run under Jetty, but mostly these commercial sites
obscure the server id.

As you probably already know, Jetty has been a leader in the area of
async.
servlet processing (aka "Continuations": http://docs.codehaus.org/display/JETTY/Continuations)
and we've already integrated this capability into the GWT remoting
framework
(http://docs.codehaus.org/display/JETTY/GWT) - we'd love to work
with the GWT team to make that integration even better.

As far as Jetty/Tomcat differences go, since servlet spec 2.5 there
is
much less scope for spec ambiguities to cause different behaviour
between the 2 servers, and generally speaking what runs on one will
run on the other. We've hardly received any portability issues at all
since
spec 2.5.

Of course, should a portability issue arise, we're more than happy
to work with the GWT team to resolve it.

best regards
Jan

[Snakey]

+1 Jetty

[Alex Epshteyn]

Bruce,

I might be too late in replying to this thread, but I want to phrase
my objections to what you've proposed.

A. Regarding Jetty:

I think this will be a waste of time for everyone. Switching
underlying servers is a "no value added" task (using Six Sigma
vocabulary).

1). Many developers are using -noserver so for them this will make no
difference.

2). Many other developers have customized the embedded Tomcat to suit
our needs (I spent hours customizing it so that I don't have to run
with -noserver). It will take hours to re-adjust again if you switch
underlying servers.

3). Why? What's the benefit of switching to Jetty? Tomcat startup is
like 5 seconds tops, which accounts for maybe 10% of the hosted mode
startup time. You should speed up the compiler if you want to speed
up hosted mode. I don't understand what Jetty has to offer here.
I'd be happy if you proved me wrong here, though.

B. Regarding the output directory structure:

I feel the same way about this as I do about Jetty. I think this is a
waste of time - no real value added to GWT. Most of us will have to
re-tweak our ant build configs which is always a waste of time.

C. Final thoughts

I'm really looking forward to seeing something of substance in the
roadmap for 1.6, because between what you've written here and what's
marked with 1_6_RC on the issue tracker, I see nothing of any value
except minor bug fixes.

Here are the top 3 features that I think would add real value to GWT:

1). A way to get meaningful Java line number from Javascript
exceptions thrown in a deployed production app (compiled with -style
OBF)

2). Out-of-process hosted mode (to enable using different browsers in
hosted mode).

3). A Declarative UI framework (one was started by Joel W. but seems
to have been abandoned).

4). Speed up compilation

Java 5 support would have been #1 on this list a year ago. You guys
did a great job with GWT 1.5 - it included at least 2 giant leaps
(Java 5 and the JSO/DOM framework), and I hope to see another big leap
like that on the roadmap instead of features that add little value to
GWT, like Tomcat vs. Jetty.

In the end, if you decide to go forward with Jetty, I can come to
terms with that, but I will need a good reason to upgrade to 1.6, like
one of the 4 items on my list.

Thanks for your time,
Alex

>
> On Oct 13, 4:48 pm, "Bruce Johnson" <br...@google.com> wrote:
>
> > Hi everyone,
> > Hope you're enjoying 1.5.
>
> > The GWT team has started putting together a 1.6 roadmap, which we'll publish
> > as soon as we have it nailed down. Two of the areas we want to work on for

> > 1.6 are some improvements tohostedmodestartup time and a friendlier

> > output directory structure (something that looks more .war-like).
>
> > As part of this effort, we've all but decided toswitchthehostedmode

> >embeddedHTTPserverfromTomcattoJetty. Would this break you? (And if so,

[Reinier Zwitserloot]

To summarize Alex' complaint:

Your plans will add hardship to my work. Please don't do that.


That's a fair point, but I believe this point was understand from the
start. What size app do you have, if the 4 second bootup time for
tomcat doesn't bother you? It must be enormous. Hosted mode doesn't
compile anything, it interprets, that's why it starts up so much
faster than actually compiling it.

OOPHM is still being worked on actively by the core GWT team, if the
chatter in gwt-contributors is any indicator. It hasn't been
abandoned.

On Nov 22, 12:54 am, Alex Epshteyn <alexander.epsht...@gmail.com>
wrote:

[rakesh wagh]

jetty or tomcat, no problem for us. But startup speed certainly is!
we use -noserver with jboss/oc4j and weblogic.

Few thing I would like to propose/request in upcoming release:
#1. Seamless hot deployment for any source code change(class signature
as well as stmt changes). So when the user refreshes the browser, js
compilation does not take place. it will just load whatever exists.
Hot deployment will make sure that whatever exists is always current.
I know this is difficult to achieve but if it is implemented, the
development time will be super super fast. We will basically have to
run the app in hosted mode browser only once. And all subsequent
changes will be auto deployed(synched) with the hosted mode. In big
applications like ours, almost every code change requires hosted mode
refresh. And in most cases it takes any where between 50 to 200 secs.
#2. If #1 is not possible: gwt should atleast detect the files that
were changed since app was last refreshed and attempt to compile load
only those changes.


Some how the compiler/loader/linker should be smart enough to the
level where hosted mode refresh is reduced to less than 7 seconds.

Really looking forward towards a super fast hosted mode.

Thanks,
Rakesh Wagh

[Sumit Chandel]

Hi Alex,

I'm interested to learn more about your use case, as it is possible that there are things we haven't considered the next move from 1.5 to 1.6.

Specifically, the move to Jetty seems like it's a net win because of the start up time improvements. Making hosted mode faster will require a combination of tweaks across the board, from which embedded server it's using to the way it refreshes and picks up code changes. Every second counts, and it seems to me like shaving off a good four seconds is well worth it if all that's required is a switch of the embedded server.

I agree that developers who are using -noserver will not see any benefit by making the switch, but developers who are still depending on hosted mode's embedded server or those who are just starting out will get better startup performance as a result.

About using a customized Tomcat to avoid -noserver hosted mode - I'm not entirely sure I understand why you would want to hack a custom version of the embedded Tomcat server rather than use your own customizable Tomcat server with the -noserver option. The embedded server wasn't really purposed to be a hackable component and was instead meant to serve as a quick way to get your application setup for early stage hosted mode debugging. Could you give more details about how you're using the customized embedded Tomcat and why it wouldn't be possible and even better to use your own Tomcat with -noserver?

Finally, about the new WAR directory structure, I agree with you that it would suck if it forced developers to re-tweak their build scripts if they've already been written in a way that depends on the current output directory structure. What I feel would be necessary here would be to pass in flags that could determine the directory structure style. I believe the upcoming support for the WAR directory structure itself would be really useful to developers as they would be able to directly deploy their application from the generated files and directories directly. What's more, it could simplify some build scripts that have been tweaking the current output directory structure to better match the WAR convention. The best place to continue this discussion would be at the GWT Contributors thread linked below:

GWT-Contributors:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/130d3f120ee8671a

The features you mentioned in your final thoughts are all things the team has thought about, and that some have actively been working on. OOPHM is still in active development as is the Declarative UI framework, as Reinier mentioned. There's also been some research into making the compiler faster. I can't say as much about the Java line from JavaScript exception feature, but it sounds like it would be a great feature to have (and a great candidate as a Request For Enhancement on the Issue Tracker).

Issue Tracker:
http://code.google.com/p/google-web-toolkit/issues/list

Cheers,
-Sumit Chandel

[Alex Epshteyn]

Hi Sumit,

> Could you
> give more details about how you're using the customized embedded Tomcat and
> why it wouldn't be possible and even better to use your own Tomcat with
> -noserver?

I'm not using -noserver because I figured it would be easier to
run/stop just one process during development than 2. Bottom line: I
think that it's faster to develop without the -noserver option. IDEs
don't have perfect support for Tomcat and using GWT's embedded server
just seems easier.

I just have two tweaks in GWT's tomcat directory - one to ROOT.xml, to
provide what my production WAR has in it's context.xml (namely,
cookies=false) and the other to the ROOT/web.xml - to provide my own
servlet/filter definitions. There's a good chance I will be able to
adapt Jetty this way as well, so I don't want to spoil the party if
everyone thinks Jetty is the way to go :)

> Finally, about the new WAR directory structure.

I agree with your intentions here. You're right, the need to build a
WAR after GWT compile seems like an unnecessary step right now, and is
certainly a pain point for beginners. (I was fortunate to find a
really good sample build.xml file on the web when I was just starting
out with GWT two years ago). If you're going to modify the compiler
to produce a WAR, I hope you will consider making this process
pluggable so that one could add their own build logic to it (for
example, my build.xml creates a gzipped copy of all the .cache.* files
to go into the WAR). Either way, I completely support having this
step be optional based on flags.

> I can't say as much about the Java line from JavaScript exception feature,
> but it sounds like it would be a great feature to have (and a great
> candidate as a Request For Enhancement on the Issue Tracker).

It's already on the books (I should have included the link in my original post):

http://code.google.com/p/google-web-toolkit/issues/detail?id=2702

This is a really important feature for me. In the interim, I was
thinking of using Soot to instrument my Java code to manually keep
track of the call stack. This will probably make the resulting JS
really slow and bloated, but might be an interesting experiment.

Glad to hear you guys are still working on the Declarative UI concept and OOPHM!

Thanks,
Alex

[Charlie Collins]

I know I am late to this thread, but Jetty would break a ton of stuff
for me (I maintain the GWT-Maven plugin, which tweaks the embedded
Tomcat) - even so, I would say it's a good idea (a lot of advantages),
and I can adapt.

One thing in this thread that concerns me though is the general
"everyone uses noserver beyond the basics" sentiment, I don't think
that's accurate - regardless of what the embedded server is (Tomcat or
Jetty or whatever).

"About using a customized Tomcat to avoid -noserver hosted mode - I'm
not entirely sure I understand why you would want to hack a custom
version of the embedded Tomcat server rather than use your own
customizable Tomcat server with the -noserver option. "

I customize the *embedded* Tomcat because without it I *can't run
GWTTestCase based tests* - and thats HUGE in my book. (The JUnitShell
doesn't support -noserver as far as I know? If I am incorrect on that
front please advise - how do others work with tests if they are using
noserver?) I don't use GWTTestCase tests for my UI either (I don't
think that's helpful at all), rather I use them for my client side
model and controller, and RPC calls and such, those tests
("integration" if you will). Also, having to debug separate processes
when using noserver is more of a pain than simply NOT having to if you
are tweaking the embedded server. I think the entire development cycle
is just faster if I don't have to re-up server side resources in a
separate process, etc.

I can basically accomplish just about any complicated JEE setup with
Tomcat, and therefore with the embedded Tomcat too. I use the Maven
plugin to handle the details, but it can be done, and I think often is
done, whether or not you are using Maven. (Because I am using the
plugin, I don't have to hand tweak it, but I have a *source* web.xml
that gets applied, and the classpath from my maven project is used,
and so on from there.)

Here is what we do to the embedded Tomcat from the plugin, for the
record: http://gwt-maven.googlecode.com/svn/docs/maven-googlewebtoolkit2-plugin/tomcatlite.html.

And I apologize in advance if this sounds like I am trying to pimp the
plugin, I don't mean to, just trying to answer the "why you would want
to tweak the embedded Tomcat" question, which applies no matter how
you accomplish it.







On Nov 24, 5:13 pm, "Alex Epshteyn" <alexander.epsht...@gmail.com>
wrote:

> >http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...

[Arthur Kalmenson]

I was going to ask if the embedded Tomcat has to be used in
GWTTestCases. It seemed like that to me, and if switching to Jetty
will speed up launching GWTTestCases (or GWTTestSuites), that's going
to be very nice for our builds.

--
Arthur Kalmenson

[Not Ken Shabby]

I will be using TOMCAT as the target server for the foreseeable
future.

My concern with switching to JETTY within the development environment
is that bugs / issues with the interaction of GWT and TOMCAT may not
be seen / address as quickly as they might otherwise be.

There may also be some "psychological / political" effect --- "oh, GWT
is something that works with Jetty, it used to work with Tomcat but
they changed it"

[AB]

I am using -noserver so it doesnt matter and even if I wasnt, i could
live with either.

[Alex Epshteyn]

I've been mulling this over the past couple of weeks, and now I want
to retract my initial objection about Jetty :) Mainly because, as
Arthur and others pointed out, it's expected to speed up unit tests
(which would be a huge win). And you don't need -noserver for most of
the unit tests you might want to run - the default settings should be
sufficient. Therefore this is one area where even the "-noserver"
crowd can benefit from a faster embedded server.

[Reinier Zwitserloot]

Not Ken Shabby:

Imagine here your -exact- reply, except swap 'tomcat' (note: it's not
an acronym, you don't need to capitalize it. Jetty isn't either) with
'jetty' and vice versa.

In other words, your argument is only relevant for you. It makes for
an excellent reason to switch for those running the end result on
jetty.

[Miles T.]

Switching to Jetty won't break me. Actually, if you were switching to
Jetty... 7 (that is to say with support Servlet 3.0 spec, especially
support for continuations), I would be really glad !!!

On 3 déc, 01:44, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Not Ken Shabby:
>
> Imagine here your -exact- reply, except swap 'tomcat' (note: it's not

> an acronym, you don't need to capitalize it.Jettyisn't either) with

> 'jetty' and vice versa.
>
> In other words, your argument is only relevant for you. It makes for
> an excellent reason to switch for those running the end result onjetty.
>
> On Nov 26, 3:55 am, Not Ken Shabby <notkensha...@gmail.com> wrote:
>
> > I will be using TOMCAT as the target server for the foreseeable
> > future.
>

> > My concern with switching toJETTYwithin the development environment

> > is that bugs / issues with the interaction of GWT and TOMCAT may not
> > be seen / address as quickly as they might otherwise be.
>
> > There may also be some "psychological / political" effect --- "oh, GWT

> > is something that works withJetty, it used to work with Tomcat but

[Arthur Kalmenson]

Well, I didn't say that it promises to increase unit test speeds :P, I
was asking if it would. It does make sense that it would since unit
tests require for hosted mode and tomcat to be launched.

--
Arthur Kalmenson

[markww]

Yay Jetty.

On Dec 5, 2:50 pm, "Arthur Kalmenson" <arthur.k...@gmail.com> wrote:
> Well, I didn't say that it promises to increase unit test speeds :P, I
> was asking if it would. It does make sense that it would since unit
> tests require for hosted mode and tomcat to be launched.
>
> --
> Arthur Kalmenson
>
> On Tue, Dec 2, 2008 at 2:43 PM, Alex Epshteyn
>

> <alexander.epsht...@gmail.com> wrote:
>
> > I've been mulling this over the past couple of weeks, and now I want
> > to retract my initial objection about Jetty :)  Mainly because, as
> > Arthur and others pointed out, it's expected to speed up unit tests
> > (which would be a huge win).  And you don't need -noserver for most of
> > the unit tests you might want to run - the default settings should be
> > sufficient.  Therefore this is one area where even the "-noserver"
> > crowd can benefit from a faster embedded server.
>