On Tue, 22 May 2001, Martin van den Bemt wrote:
> Hi,
>
> I just installed tomcat 4 and some things are looking good (didn't deploy my
> current applications yet under tomcat 4), but one of the big issues when
> running a server that must be online 24 hours a day, is upgrading the server
> with new classes / configs etc. The current "stable" tomcat doesn't reload
> stuff correctly all the time and tomcat 4 solves these problems (at least
> that is my understandig from the docs). I would like to take a step further
> : using a tomcat internal version control system, so that you can go back to
> the previous version(s) of your webapplication without any trouble.
> Lets first point out the perfect world scenario (the it supposed to be, or
> reasons why the above idea is bad ) :
>
> - You're code should always be tested (ahum...)
> - You should write test cases (eg jUnit)
> - You should do integration tests on a separate server, to see if everything
> is still ok.
> - You shouldn't write buggy code (ahum..)
> - Version control is in CVS..
>
> Now the arguments that support my version control wish :
>
> - We're humans and make mistakes (which can be deadly on a production
> server)
> - Version control in CVS is limited and too much time consuming
> - All scenarios can be tested, but if you have eg 2000 shops running at the
> same time and all the shops have been made under a different release and
> changed in different releases, it's hard to test that (it is possible, but
> very time consuming).
> - If you can go back with a "press on the button" scenario, the customers
> are happy again.
> - Better possibilties for remote managament of servers and version control
> (not all our customers give us the access to eg telnet, which makes it
> harder to use cvs amd ant for this).
>
> If I missed some reading and this is on the list to be done, let me know
> :-)
>
> Do you (=the developers) like that idea?
>
Hello Martin,
It's hard to know how to answer that question, because I'm not quite sure
what you're proposing. Let me try a few assumptions about what you're
suggesting and make some comments on them:
VERSION CONTROL ON YOUR OWN WEBAPPS. This makes a lot of sense, but
doesn't directly involve Tomcat. I would suggest looking at how you could
use the Manager webapp to undeploy and redeploy applications on the fly,
without having to restart Tomcat. It should be feasible to script this.
VERSION CONTROL TO AUTOMATICALLY SWITCH TOMCAT VERSIONS. If you want
this, you're probably going to need to work out a set of shell scripts for
your deployment platform that does all the work. However, I don't see
right now how you could use this to switch Tomcat versions "on the fly" --
the way that this works for webapps is to throw away the web application
class loader (and thus all the classes loaded by it). Trying to do this
on the running classes of Tomcat itself is going to be problematic.
WRITE UNIT TESTS FOR TOMCAT. If you are volunteering to write JUnit based
unit tests for the server side components of Tomcat, your contributions
would be very welcome. I would like to see us begin doing this.
WRITE UNIT TESTS FOR WEB APPS. If you want to write unit tests (or
end-to-end tests) for your own web applications, a technology you might
want to investigate is Cactus (from the Jakarta Commons project at
<http://jakarta.apache.org/commons/cactus/>). This is a framework focused
on writing tests for web applications.
> I would be happy to invest time in this (to build it), but I never peeked at
> the source before, so I don't know yet what I'm volunteering for...
>
Well, I'm not sure that I've covered what you mean by the "it" you want to
build. Could you be a little more specific about what you propose?
> Mvgr,
> Martin
>
>
Craig
