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" <[EMAIL PROTECTED]>
wrote:
> 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
>
> On Mon, Nov 24, 2008 at 3:44 PM, Sumit Chandel <[EMAIL PROTECTED]> wrote:
> > 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...
>
> > 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
>
> > On Fri, Nov 21, 2008 at 3:54 PM, Alex Epshteyn
> > <[EMAIL PROTECTED]> wrote:
>
> >> 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" <[EMAIL PROTECTED]> 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,
> >> > > 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 theirserverconfig.
>
> >> > > Thanks,
> >> > > Bruce
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
