On Tue, 22 May 2001, Martin van den Bemt wrote:
> Hi Graig,
> >
> > 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:
>
> My writing can get "unclear" at certain moments. While I'm typing, most of
> the time I'm already thinking of 2 lines ahead ;-))..
>
I know that feeling ... and I can never seem to type fast enough to catch
up :-)
>
> > 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.
>
> This is what I was looking for..
> Scenario :
>
> We're at version 1.5 of our webapp
> We install it on all the servers, but on some servers we want to just still
> run 1.3, but also have available there the 1.5 version of the system. At an
> agreed moment with the customer we switch to the new version (or schedule
> the switching of version in the night). This way were able to put the latest
> stuff on all the server and without actually "directly" have to worry about
> upgrading the system at that moment and worrying : what is running where and
> can we upgrade there, etc,etc.. Even possibilities of running rules for the
> upgrade (eg we need to update al the shop configuration files) and downgrade
> where possible.
>
> So :
> - Upgrade to a version without actually using it at the time of the upgrade
> - Upgrade through a scheduler or downgrade / rollback.
> - Being able to write "rules" for upgrading / downgrading a system (we can
> have some default rules, like "Downgrade not possible".
> - Do it remotely (which is possible via the Manager, as I understood).
> - Also (the rules can be used for this) is release management for content
> not served by tomcat, but eg by apache. (we serve pictures, javascript and
> dtd's on apache for speed).
>
> Volunteering for this I think ;-))
>
It looks like a mechanism to use the Manager servlet behind the scenes
might to this.
> > VERSION CONTROL TO AUTOMATICALLY SWITCH TOMCAT VERSIONS.
>
> nah.. let's not do this one..
>
Good -- I'm not sure it's actually feasible :-).
> > 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.
>
> Is very good for me probably to start learning about tomcat 4 (how it's
> build) and jUnit.. (I didn't dig into that yet).
> Any suggestions/examples on this part are appreciated.. (where to start,
> what needs to be tested (functionality..), what to look out for, etc).
>
> Volunteering for this first ;-))..
>
Cool ... as you saw, I just checked in a starting point for the Catalina
tests. You can use that as a model for how to fit new tests into the
infrastructure, and them propose them to TOMCAT-DEV as patches, following
the guidelines on the Jakarta web site.
> > WRITE UNIT TESTS FOR WEB APPS.
> > <http://jakarta.apache.org/commons/cactus/>).
>
> Have it, but don't use it yet.. Some tests on the default webapps in tomcat
> 4 should also be made?
>
That would be a really cool idea -- it would both prove that the example
webapps work, and also be useful as models for end-to-end tests.
> Mvgr,
> Martin
>
>
>
Craig
