[OT?]Tomcat multiple users developing
Hello, we are 3 developers currently developing a web site with struts. The problem we are facing is that every time a user makes a change to the code or to the struts.xml he has to reload the application: this involve a great loss of time. I'd like to know: 1) How do you share the same application developement? Do you use a strategy? We are testing our business objects outside struts, but the final test is always something that depends on tomcat, so we need the last version of the code on tomcat very often... 2) Is there another way to tell Tomcat that a class has been changed instead of reload the application or set the reload=true attribute in the context? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT?]Tomcat multiple users developing
Why don't you have separate tomcat installation for every developer? Each developer can periodically synchronize with the repository to keep uptodate.But since the server installation is separate, he can restart it as many times he wants without affecting others..That is teh strategy we are using in our project(1 team of 7 java developers). HTH. regards, Shirish -Original Message- From: Leonardo Francalanci [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 10:12 AM To: [EMAIL PROTECTED] Subject: [OT?]Tomcat multiple users developing Hello, we are 3 developers currently developing a web site with struts. The problem we are facing is that every time a user makes a change to the code or to the struts.xml he has to reload the application: this involve a great loss of time. I'd like to know: 1) How do you share the same application developement? Do you use a strategy? We are testing our business objects outside struts, but the final test is always something that depends on tomcat, so we need the last version of the code on tomcat very often... 2) Is there another way to tell Tomcat that a class has been changed instead of reload the application or set the reload=true attribute in the context? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT?]Tomcat multiple users developing
1) How do you share the same application development? Do you use a strategy? We are testing our business objects outside struts, Are you all sharing a single tomcat instance for development? If so, stop now! :-) Set up a version control system (like cvs), and use one instance of tomcat per developer (on each workstation). That way only your changes affect you. Update from cvs often and commit when your code works. 2) Is there another way to tell Tomcat that a class has been changed instead of reload the application or set the reload=true attribute in the context? No. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT?]Tomcat multiple users developing
- Original Message - From: Larry Meadors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 10:47 AM Subject: Re: [OT?]Tomcat multiple users developing 1) How do you share the same application development? Do you use a strategy? We are testing our business objects outside struts, Are you all sharing a single tomcat instance for development? If so, stop now! :-) +1 Set up a version control system (like cvs), and use one instance of tomcat per developer (on each workstation). That way only your changes affect you. Update from cvs often and commit when your code works. 2) Is there another way to tell Tomcat that a class has been changed instead of reload the application or set the reload=true attribute in the context? No. Actually, that's not totally true. When running Tomcat and attaching via Remote Debugging (or using something like MyEclipse), you can change and save (which Eclipse automatically compiles for you) your code at will and you will be able to execute that new code by just refreshing your browser. Or even better, if you set a break point in a method and as an executing thread comes to (and freezes on it) that peice of code, you can change anything in that method and execution will restart from the top of that method. As long as you don't change the signature of a preloaded class (binary compatibility), you can change all you want, on the fly. Good stuff for lazy people! (like me ;) Larry -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 (cell) AIM: jmitchtx MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]