tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <>
Subject Re: WebappLoader RFC
Date Tue, 13 Jun 2006 23:55:37 GMT

Its unclear now what you are trying to fix.  Your first post stated you 
wanted to cut down on the "deploy" part (I pointed out the features we 
currently get that we'd loose with your approach; also that deploy is 
necessary to flush out the old version of the code in the JVM) and this 
last post I get the impression you want to cut down on the "build and 
copy JAR to WEB-INF/lib" step.

I think I understand your situation as I have been there too but lets 
work through your points.

Glen Marchesani wrote:
> The IDE features you mention sound cool which one is it?

I don't want to get into any religious IDE war but Eclipse 3 with WTP 1.0.

> Any pointers/links
> to how you got that setup?

See below for the outline.

> Unfortunately for the environment I am working
> in an IDE specific solution would be incomplete.  We have a broad range of
> use cases (IDEs, OSes) as well as users where we need people to be able to
> checkout a project and be productive with it in a minimal amount of time.
> So doing IDE specific tweaks won't cut it.  Our solution has worked
> extremely well with other app containers for example WebSphere, Resin and
> Jetty (all three that we use) come with support for something like this out
> of the box.

I understand what you are saying, from your commercial standpoint you 
see the lack of this feature as causing a headache in supporting your 
customer base container diversity.

My point from a technical standpoint your feature is already obsolete 
since at least one popular IDE already has a working solution which 
probably works for all containers the IDE supports (I've never tested on 
anything but TC) which includes the ones you list above.  It is just 
matter of time before the other popular IDEs play catch up.

> The IDE we use really depends on the customer, project and environment.  So
> could be any of the following ant+text editors, eclipse, WSDC, and/or
> netbeans...  We can seemlessly switch between any of these using this
> technique by just adding the extendedClasspath line to the context and
> dropping a jar in server/lib/ all of which is handled by our ant scripts.
> I am all for continuing this tangential discussion of webapp development
> techniques but it really is tangential to the intent of the original post..

I'm not against your feature per say just the reasons you cite the need 
for it.

> Hot-code replace works fine in this scenario, I get the impression that you
> think it doesn't.  As for your comments about future proofing.  I am very
> confident that IDE's will from now on into the future will compile my .java
> files to some directory on the disk and that this option will be
> configurable and use some consistent default.  So this solution is
> completely future-proof.
> In all the "jar exporting to WEB-INF" stuff I have seen in various IDE's 
> you
> need to manually kick off that process so it is adding a step to the
> edit-compile process.

Are you really sure hot code replace work fine in this scenario, I 
thought the IDE had to be able to understand from its internal 
dependency graph that the compiled .class file is running on the JVM to 
be able to push an update to that JVM.

The situation you present sounds like you have a web-app running under 
TC under the IDE and another standalone java project in the IDE.  If you 
edit this standalone project sure you get a compiled .class file out of 
it, but why would the IDE then offer it up to the TC JVM ?  For all 
intents and purposes the standalone project is disconnected from the 
running web-app.

Since Eclipse WTP 1.0 you can create a J2EE Utility Project which can 
contribute a JAR into the WEB-INF/lib of J2EE Dynamic Web Project 
(create those 2 project types, goto the Project Properties page J2EE 
Module Dependancy of the DWP and tick the box).  You can have both 
projects open and develop them at the same time with the IDE 
automatically propagating the new compiled code.

This feature is still not perfect since TC will auto-redeploy when a JAR 
changes, the WTP feature would be better if it had a toggle to allow the 
J2EE Utility Project exported as individual .class files into the 
WEB-INF/classes tree this would allow Eclipse to attempt a Hot-code 
replace and thwart some unnecessary TC reloading.

In any case if you alter the fields of a class which has one or more 
active instances Sun's JVM doesn't allow that class to be 
hot-code-replaced you get an error and Eclipse offers to 
continue/restart/shutdown the JVM.  But there are many common cases 
where it works well, like adding/changing methods.

Eclipse's solution is nearer my vision of the future and generic this 
makes it future proof to me.  What you are proposing as a solution to 
this problem is a band aid, a dead end; that prohibits the next step to 
be taken by the IDE towards the ultimate seamless developer experience. 
  Geez I should try marketing.

>  Effectively adding a deploy step so you have
> edit-compile-deploy.  Which is exactly what I am trying to avoid albeit if
> it is properly contained in the IDE it is less of a headache.

This is back to my opening question.  Which bit is the tedious task for 
you at this time ?   The "having to click a button", the "compile, build 
JAR, copy JAR to web-app" or the "waiting for the reploy to complete" ?

These were (before WTP 1.0) the only productivity killers for me.

The first and second problem have been solved.

The third problem has room for improvement (by reducing the cases where 
a redeploy is necessary) but at this time serves a useful purpose of 
flushing out the old version of code from the container, causing the 
container to re-read tag descriptors, causing the container to flush all 
tag-pools, causing the web-app to re-read config files, blah blah, so 
there are still many changes where a redeploy just can't be avoided.

> I enjoy the discussion of good practices (I don't think there is a one size
> fits all best practice here) for having a smooth development process so 
> keep
> it coming ;-)

There are a number of little gems of info that maybe useful, like making 
sure you setup a META-INF/context.xml and use a <Context ... debug="1" 
reloadable="false"> then sit back and let Eclipse do the right thing.

Eclipse itself has room for improvement, like it shouldn't update the 
timestamp on files which have not changed.  The container correctly 
thinks it is a new file version when infact no net change occured but 
the lame building tools updated the target anyway.  There are some 
really lame components which truncate files to rebuild them, rather than 
write to a .tmp file, do an overwrite-if-modified check.  These things 
all contribute to unnecessary web-app redeploys which impedes productivity.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message