Re: Version control in tomcat 4...
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
RE: Version control in tomcat 4...
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 ;-)).. 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 ;-)) VERSION CONTROL TO AUTOMATICALLY SWITCH TOMCAT VERSIONS. nah.. let's not do this one.. 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 ;-)).. 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? Mvgr, Martin
RE: Version control in tomcat 4...
Hi Craig, Saw your commits ;-)) Mvgr, Martin
RE: Version control in tomcat 4...
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
