Re: Problems with deployment process using Eclipse + Ant + Tomcat
We use ant build scripts (launched from eclipse, anthill, command prompts, just about anywhere) to deploy webapps to Tomcat and it works fine for us. But we did have difficulties when we started doing so. We are currently using Tomcat 5.0.28; we've done it for a long time on Tomcat 4.1; we've tested it on Tomcat 5.5, but I can't say that it worked - we had other issues (unrelated to ant or Tomcat) that got in the way. Its been a while since I went through these problems, but here's my recollections: a) There are several tasks in the catalina-ant.jar. In particular, though, there are two different sets of tasks that can be used for deploying webapps: / and /. You cannot a 'd app nor can you an 'd app. I don't fully recall the difference between those sets of tasks, but we discovered that the / tasks worked better for us. b) We change the unpackWars attribute in the element of the server.xml from true (its default value on a Windows installation) to false. Without this change, Tomcat unpacked the deployed webapp, which caused difficultied with the removal (files weren't removed) which then prevented redeployment. c) Side note about your ant scripts: your "deploy" target uses a bunch of ant calls to do different things (build, war, tomcat_deploy and email). In each case you are passing inheritrefs=true and inheritall=true and calling targets in the same build file. You'd probably be better off just doing this as dependencies instead: I hope that helps, -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging and Deployment best practices
Phillip Qin writes:
Hi, I don't think the log will go to system32 directory.
Try something like this
log4j.appender.file.File=${catalina.home}/logs/lciponline_debug.txt
It will when I just do this, though:
log4j.appender.file.File=lciponline_debug.txt
Using the environment variable was the trick that I didn't know about.
Thanks for your answer!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging and Deployment best practices
Shapira, Yoav writes: Loggers are gone in Tomcat 5.5. One gentle suggestion: Is it possible make a note of that in the server configuration documentation? I was reading http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/logger.html and was just getting interested in them before reading a post on the topic this morning. Thanks again, PC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging and Deployment best practices
On Tue, 23 Nov 2004 10:14:24 -0500, Shapira, Yoav <[EMAIL PROTECTED]>
wrote:
>a) Convert my log4j.properties file to use a RollingFileAppender. I
This is good.
>I'd rather use a relative path (something like ./logs) and
>have the logs all end up in %TOMCAT_HOME%/logs.
Log4j configuration files can have environment variables in them, e.g.
${CATALINA_HOME}/logs/mylog.txt. Alternatively, you could use
programmatic configuration instead of log4j.properties.
Cool! I guess it pays to know where to look. I've been digging through
Tomcat documentation to find an answer, when I guess I needed to read the
log4j documentation.
I want to stay away from programmatic configuration of log4j, and just use
property files. Using an environment variable gives me the flexibility I
need.
Thanks for your answers!
--
PC
Paul Christmann
Prior Artisans, LLC
mailto:[EMAIL PROTECTED]
504-587-9072
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Logging and Deployment best practices
We've recently upgraded from 4.1, which we've been using for 2+ years, to 5.0.28. While doing this, I've been looking into our logging in order to try and do things better. And I'm curious what other people do - if there are any "best practices" that I could follow. What we do today: We use log4j (wrapped inside commons logging) in our webapps. Each war file includes a jar that has a log4j.properties file which controls logging from that webapp. We use the log4j ConsoleAppender so that all of our log messages ended up in the tomcat stdout.log file. It was always a minor annoyance that we had to manually back up those files when we did a restart of the service (we are using W2K and XP servers). But I finally decided as I was upgrading Tomcat that I'd address that problem by moving to a rolling file appender. Seems to me that I have two choices for doing this: a) Convert my log4j.properties file to use a RollingFileAppender. I did this, and much to my surprise the log files showed up in my %WIN_HOME%/system32 folder. Try as I might (for example, setting AppDirectory inside Parameters using the Registry Editor), I couldn't figure out how to change the home directory for Tomcat running as a Service. We have different installation of Tomcat on different servers, so I can't (nor do I want to) use a full path for the logging; I'd rather use a relative path (something like ./logs) and have the logs all end up in %TOMCAT_HOME%/logs. b) Leave my log4j.properties file using ConsoleAppender and use a element in my to have Tomcat put the output into a file. I have not tried this yet, and wanted to post this query before digging further into it. Is this a good alternative? I have two issues with it: i) I just saw another post that indicated that this functionality is being removed in 5.5. Seems like the wrong time for me to start using functionality that has already been removed from future versions. ii) We use ant tasks to deploy our war files to multiple contexts. We have never included a context.xml in our webapps, instead getting the "default" behavior when we deploy. If I included a context.xml in the war file, then I can't deploy the exact same war (checked out from CVS) to a new context without modifying it. Or can I? (Sorry - the whole META-INF/context.xml is very new to me. I only started reading about it yesterday). We do deploy the same war file to different contexts: for development and staging environments. So: what is the "right" approach for file logging in a webapp under Tomcat? + Put all of the responsibility into the webapp using log4j? If so - how can I configure the home directory of Tomcat when I install the Service? Or should I hardwire some other location for the logs? + Or use the logging functionality of Tomcat via elements? If so - how do I manage deploying the same webapp to different context paths? + Some other alternative? Thanks for any insights, -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.28 Service Shutdown problem on Windows
OK, many thanks. I'll check back with bugzilla later. Shapira, Yoav wrote: Hi, Bugzilla is having a tough day: its admins ([EMAIL PROTECTED]) are aware of the problem and working on it. There's an open issue with what you describe: destroy not being called when Tomcat is run as a Windows service for Tomcat 5.0.28. The issue was first reported in an early 5.0 version, fixed for 5.0.16 or 5.0.19, and now apparently has re-appeared. Yoav Shapira http://www.yoavshapira.com -Original Message----- From: Paul Christmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 3:53 PM To: [EMAIL PROTECTED] Subject: 5.0.28 Service Shutdown problem on Windows I just upgraded from 4.1.30 to 5.0.28 on two windows machines: one XP and one W2K. Both of them are having the same problem: When I stop the installed Tomcat service, the destroy() method on my servlets does not appear to get called. I do not get my logging information from my destroy methods, and file handles that should get closed are left open. The last message in my Tomcat stdout.log is: INFO: Pausing Coyote HTTP/1.1 on http-8081 When I run Tomcat standalone (using bin/startup and bin/shutdown), this message is then followed by additional logging information and the destroy() method of my service gets called. When I run bin/shutdown, it returns before the full Tomcat shutdown is completed. In fact, to my untrained eye it appears to return shortly after the "Pausing" log message. So it appears that when running Tomcat as a service, the service is getting halted when shutdown finishes - which has Paused the service. But the remainder of the shutdown process is not invoked. I've used the Windows installer, and made only four modifications to the installed service: + I replaced tomcat-users.xml + I changed the unpackWARS from true to false + I installed my webapp + I changed the service to run under a specific user account I've exhausted my google skills searching for answers, but to no avail. I tried to search bugzilla but got SQL errors (is that a known problem? I followed the instructions on the error page and sent an email with the error message to [EMAIL PROTECTED], which seems too generic for that type of error message). -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.0.28 Service Shutdown problem on Windows
I just upgraded from 4.1.30 to 5.0.28 on two windows machines: one XP and one W2K. Both of them are having the same problem: When I stop the installed Tomcat service, the destroy() method on my servlets does not appear to get called. I do not get my logging information from my destroy methods, and file handles that should get closed are left open. The last message in my Tomcat stdout.log is: INFO: Pausing Coyote HTTP/1.1 on http-8081 When I run Tomcat standalone (using bin/startup and bin/shutdown), this message is then followed by additional logging information and the destroy() method of my service gets called. When I run bin/shutdown, it returns before the full Tomcat shutdown is completed. In fact, to my untrained eye it appears to return shortly after the "Pausing" log message. So it appears that when running Tomcat as a service, the service is getting halted when shutdown finishes - which has Paused the service. But the remainder of the shutdown process is not invoked. I've used the Windows installer, and made only four modifications to the installed service: + I replaced tomcat-users.xml + I changed the unpackWARS from true to false + I installed my webapp + I changed the service to run under a specific user account I've exhausted my google skills searching for answers, but to no avail. I tried to search bugzilla but got SQL errors (is that a known problem? I followed the instructions on the error page and sent an email with the error message to [EMAIL PROTECTED], which seems too generic for that type of error message). -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Manager deploy and undeploy
Jacob Kjome wrote: > Do you add a META-INF/context.xml file containing your > information with the docBase pointing to "myapp.war"? No, I've never added that. It was only with this release that I even noticed the documentation that it was possible. But thus far I've never needed it. If one doesn't exist, post a new bug and describe how to reproduce it. Will do. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Manager deploy and undeploy
Jacob Kjome wrote: Tomcat wouldn't unpack myapp.war even if unpackWar="true" unless myapp.war actually found its way into the appBase of the host which by default in Tomcat is CATALINA_HOME/webapps. Using the Tomcat ant manager tasks to "deploy" a .war to Tomcat, this simply doesn't happen. The .war is not copied to the appBase and, therefore, does not get unpacked under the appBase. If the docBase points to the .war file, even if the has unpackWARs="true", the .war file will not be unpacked. I think this is what you are saying, although I'm not sure. I just tested it and it works just as I've described. I'm not sure what Paul is doing to get the behavior he see's??? OK, now I'm thoroughly confused. I believe your description of what you see, and I believe that is what I *should* be seeing. However, its clearly NOT what I'm seeing. And sure, I assume I'm doing something wrong, but I have no idea *what* (especially since I'm doing the same steps that worked with all Tomcat releases up to 4.1.18-LE). + I'm using the ant manager tasks for everything (org.apache.catalina.ant.DeployTask and org.apache.catalina.ant.UndeployTask). + My build file first runs "undeploy", then "deploy". + I uninstalled my old Tomcat instance, which fully removed the TOMCAT_HOME folder. + I installed Tomcat 4.1.24-LE. + I ran my ant tasks to deploy my webapp. After this, I end up with: + entry for my webapp in my server.xml that points docBase to TOMCAT_HOME/webapps/[webapp]. + TOMCAT_HOME/webapps/[webapp] containing the expaned contents of my war. + War ends up in TOMCAT_HOME/work/Standalone/localhost/manager/[webapp].war Then I have to use org.apache.catalina.ant.RemoveTask to remove the webapp (deleting the TOMCAT_HOME/webapps/[webapp] folder and the entry. *Then*, if I modify the "unpackWARs" attribute of the element in my server.xml (setting it to false) and do exactly the same steps as above, I get the behavior I expect: the webapp is *not* unpacked, and its docBase points to the TOMCAT_HOME/work/Standalone/localhost/manager/[webapp].war *EVEN* if I then change unpackWARs back to true and redploy, I get the behavior I described originally -- the WAR is unpacked! SO even once I have the correct entry, redeployment changes the entry and unpacks the war. :( Am I really the only one that is seeing this behavior??? :( :( What am *I* doing I'd really like to figure out what I've done wrong. Please help -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Manager deploy and undeploy
Phillip Qin wrote: - war is uploaded to $CATALINA/work/Standalone/my.host/manager; >> - war is unpacked into $CATALIAN_HOME/webapps/myapp; > Jacob Kjome wrote: completely false I have to agree with Phillip -- I've seen (and reliably reproduced) this behavior with Tomcat 4.1.24-LE. The only way I got around problems caused by this (undeploy would not work if the app had been unpacked in the CATALINA_HOME/webapps folder, but remove would) was to modify the distributed server.xml, adding unpackWARs="false" to the entry. I'd love to know *what* (if anything) I'm doing wrong, or have configured wrong. But I've reproduced this multiple times on 3 different Windows 2X servers with clean 4.1.24-LE installations. PC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy in 4.1.24
Aha! I found the solution, though not a completely satisfying explanation. Thought I'd post what I found in case anyone else ever encounters something similar. By changing the "unpackWARs" attribute of the Host element in my server.xml to "false", I got back the behavior I had seen in earlier releases (my war file is no longer unpacked under the /webapps folder). Going back through old versions of my server.xml (kept in CVS), I find that the unpackWARs attribute had always been present, and had always been set to "true". So I still don't know what changed with 4.1.24 to change the behavior, but I found a way to get back my old behavior. In fact, it seems that the unpackWARs behavior was not behaving properly in the old release, since the deployed war was *not* unpacked. What still seems odd, though, is that the out-of-the-box installation of 4.1.24-LE seemed to install with unpackWARs to true, which caused my war files to get unpacked. This seems inconsistent with the documentation, and with the experiences of at least one other user - where the war was not expaned. So I don't know what I did wrong, or have configured wrong. So, I don't know what happened, but am happy that I got my old behavior back on the new release! PC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deploy in 4.1.24
Jacob Kjome wrote:
All I can say is that you must be mistaken. I just performed a
with two different apps. In both cases, the .war files ended up in
work/Standalone/localhost/manager and the WEB-INF directory from those
.war files were also extracted to work/Standalone/localhost/[webapp name].
:(
I just double checked everything on my system. I did a clean
installation of Tomcat 4.1.24-LE and deployed my applications and still
see the same results: the app ends up unpacked in the
TOMCAT_HOME/webapps/[webapp name] folder. NOTE: the webapp war file
itself does *not* end up in the webapps folder, but I end up with the
named folder beneath it containing the unpacked files. I do *not* get
the [webapp name] folder underneath work/Standalone/localhost, though
the webapp war does get placed inside work/Standalone/localhost/manager/lib.
The docBase parameter in the server.xml refers to the
TOMCAT_HOME\webapps\[webapp name] location. I'm guessing that when you
tested, the docBase parameter pointed to the Standalone/localhost location?
I'm stumped.
FWIW, here's the ant task that I use (in case this wasn't clear before
-- I only use ant tasks to invoke the manager, never the manager webapp
itself):
the properties are pretty self-explanatory:
catalina.webapps.url = http://localhost:8081
catalina.manager.user/pwd are correct.
deploy.project.name is the name of my webapp ("net").
deploy.war is the name of the war to deploy ("/src/net/build/lib/net.war").
The build file (and all properties) worked fine before this upgrade, so
I'm truly at a loss.
--
PC
Paul Christmann
Prior Artisans, LLC
mailto:[EMAIL PROTECTED]
504-587-9072
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
deploy in 4.1.24
I'm upgrading from 4.1.12-LE to 4.1.24-LE, and have found what appears to be a change in behavior from the and tasks in catalina-ant.jar. In 4.1.12, the webapp appeared to be deployed to TOMCAT_HOME/work/standalone/localhost/. It was not placed in the TOMCAT_HOME/webapps folder. This appeared to work fine, though, as the app was properly deployed, it worked, it was persisted, etc. etc. etc. The task could then be 'd. In 4.1.24, war file is placed in the TOMCAT_HOME/webapps folder, and the app is deployed from there. This also works fine for deployment (the app works, persisted, etc. etc. etc.). BUT -- the fails. I can use the task to remove the app, though. Is this an intentional change in behavior? If so, is there any case where the task should (could?) be used? -- PC Paul Christmann Prior Artisans, LLC mailto:[EMAIL PROTECTED] 504-587-9072 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
