Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@www.apache.org Received: (qmail 78470 invoked from network); 13 Oct 2004 16:31:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 13 Oct 2004 16:31:52 -0000 Received: (qmail 68767 invoked by uid 500); 13 Oct 2004 16:31:05 -0000 Delivered-To: apmail-jakarta-tomcat-user-archive@jakarta.apache.org Received: (qmail 68699 invoked by uid 500); 13 Oct 2004 16:31:04 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 68669 invoked by uid 99); 13 Oct 2004 16:31:03 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=HTML_20_30,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of jnwilson@dallas.photronics.com designates 192.129.97.122 as permitted sender) Received: from [192.129.97.122] (HELO scrabble.photronics.com) (192.129.97.122) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 13 Oct 2004 09:31:00 -0700 Received: from crockett.dallas.photronics.com (crockett.dallas.photronics.com [172.16.32.42]) by scrabble.photronics.com (8.12.10/8.12.6) with ESMTP id i9DGUsJJ020801 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Oct 2004 11:30:57 -0500 (CDT) Received: from [172.16.36.11] ([172.16.36.11]) by crockett.dallas.photronics.com (Netscape Messaging Server 4.15) with ESMTP id I5J77G00.ELS for ; Wed, 13 Oct 2004 11:30:52 -0500 Message-ID: <416D5804.5030500@dallas.photronics.com> Date: Wed, 13 Oct 2004 11:29:56 -0500 From: "Jonathan Wilson" User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomcat Users List Subject: Re: reloading JSP files without reloading classes/beans References: <416AF26F.6010308@dallas.photronics.com> <1097532195.2516.9.camel@development.sequoiallc.com> <416B08B9.7000801@dallas.photronics.com> <1097683231.4412.25.camel@development.sequoiallc.com> In-Reply-To: <1097683231.4412.25.camel@development.sequoiallc.com> Content-Type: multipart/alternative; boundary="------------020802020105000406030308" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --------------020802020105000406030308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bob, thanks for all the good pointers. This is just the information about web-app development I've been needing but didn't know how to find(or what to look for). I've played with ANT a bit before, but I didn't know there was an applet to do the deployment for me(is that process portable to diff web-app servers?). I've got the same problem with session retention after a reload(if contexts' reloadable="true" that is) - and it sounds like it will still be a problem after I upgrade my development practices and start using WARs. Since you seem like a free thinker :) do you have any ideas on a solution for that problem? I was researching load-balancing Monday and came across a solution that mentioned sessions were retained on a different instance of tomcat(but were accessible to all, somehow - too much for me to digest); perhaps that will provide a path? Here's the link: http://www.onjava.com/pub/a/onjava/2004/04/14/clustering.html Regards, JW Robert Bateman wrote: >On Mon, 2004-10-11 at 18:27, Jonathan Wilson wrote: > > >>Bob, >> >> You just answered my follow up to your previous email :) >> Hmm, so I run a concurrent version of my production app(being >>careful not to impact the databases) either on a different instance of >>Tomcat or just a different context within the same instance of Tomcat. >> >> > >Yes. I use a tool called ANT to process, build and deploy my >applications via WAR files. In my ANT build file, I have separate tasks >that deploy to production and test. Because I am deploying using a WAR >file, each application has it's own configuration file (server.xml) >called context.xml. In my case, I have two different configuration >files - each specifically tailored to the environment I will deploy >into. All my ANT task does is copy the appropriate config during the >build. > > > >>Then when I'm ready I package up the source code into a WAR(what tool do >>I use for that? - must do research), copy it into the production servers >> >> > >You build the WAR file with a program called JAR. WAR files are zip >files with different extensions (in fact, you can rename a WAR file to >.ZIP and open the file for inspection.) > >As you build the WAR file, you want to compile any source modules that >need compiling and place them into WEB-INF/classes. JAR files go into >WEB-INF/lib so that the WAR file is self contained. > > > >>webapps directory(and hopefully have all the configuration set properly >> >> > >If your version of Tomcat supports it, instead of copying into the >WEBAPPS folder, you can use the manager applets' UNDEPLOY/DEPLOY >capability. This allows the server to take your WAR file and put it >into the appropriate place on the server. Under TC 4.1 and newer, I've >been using a task in ANT that communicated with the manager applet for >me and does all of the un/deploying - quite spiffy. > > > >>to auto-expand) and then what? If the WAR is automatically expanded do >>the new files take effect immediately >> >> > >I'm not sure about TC version 3 (I use 4.1 and 5.0), but on my server, >the WAR file is placed into the appropriate place and put "live" as soon >as it's deployed. I've found in my environment, that I have to be >careful not to deploy when there are active sessions because my >application doesn't handle the refresh gracefully. > > > >>or do I need to restart tomcat still. Does the context in the server.xml >>need reloadable="true" set for a WAR file expansion to take effect >>immediately? >> >> > >With WAR files, you don't touch server.xml any more. All of your web >application specific configuration parameters are placed into >context.xml in a folder called META-INF within the WAR. The server >parses this file to determine how to deploy your application, what >resources it needs, logging, etc. Nicely self contained. > > > >> Thanks for the info..connected some dots for me. >> >> New Question (While I've got ya :): Given that I can use a WAR file >>to "deploy," would you advise using Tomcat 5.x as my test server, >>creating a WAR and then deploying that to a production 3.3.1 server? >> >> > >I gotta agree with QM on this one... Test with the version that is in >production. > >Is it possible for you folks to atleast migrate up to TC 4.1.xx in >production? Your closer to current that way and migrating to 5.xx might >be easier once you feel comfortable with TC 5. > > > >>This would kinda let me test using 5.x and still support a 3.3.1 box. >>The app is very self-contained, except for a load of jar's in the lib. >> >>Thanks for you time!! >> JW >> >> >> >> >> >> > >Bob > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org > > > > --------------020802020105000406030308--