deployment / war unpacking and Context definition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, feeling kinda ashamed asking such a (probably rather basic) question, but nevertheless: By now, I only built applications packed to *.war files and then thrown to a tomcat /webapps/ folder, which obviously made / makes tomcat redeploy the application - so far, so good. However, in order to get a JDBC resource set up and running, I added a context definition like this ... Context path=/jdbclink reloadable=true ... Resource name=jdbc/SQLDB auth=Container ... / ... /Context ... and then dumped in a jdbclink.war file. Deployment works fine the very first time, and then never again. :o Even worse, removing the webapps/jdbclink/ folder while the container is running doesn't make tomcat unpack / redeploy the .war file. Likewise, even placing a new war file in webapps and restarting the container doesn't do - I have to stop tomcat and manually remove the unpacked web application in webapps to get the war redeployed again. Haven't messed with any other settings so far, the Host declaration looks like this... Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false We're talking tomcat 5.5.20 atop Ubuntu/JDK 1.6 here. Can anyone enlighten me why in this configuration tomcat doesn't redeploy the application when having a new war file dropped to webapps (by removing the Context definition from server.xml, this does work again...)? It's not all _that_ bad the way it is now, but having to shut down tomcat and manually remove the webapp to get it redeployed is not that fine on a production system running more than just that very application. :) Thanks in advance and bye, Kristian - -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGMJBJcxBAPOA1m6wRAsJjAJ9HigISz9g/4YdZ1Mv2rw+7EBt21wCbBGp+ myjQt53ccWBHayGdXzCiG5U= =fKcF -END PGP SIGNATURE-
RE: deployment / war unpacking and Context definition?
From: Kristian Rink [mailto:[EMAIL PROTECTED] Subject: deployment / war unpacking and Context definition? Context path=/jdbclink reloadable=true ... Resource name=jdbc/SQLDB auth=Container ... / ... /Context Where is the above Context declaration? If it's anywhere other than in server.xml (where it shouldn't be), the path attribute must not be present. removing the webapps/jdbclink/ folder while the container is running doesn't make tomcat unpack / redeploy the .war file. Deleting arbitrary files out from under a running process is just asking for trouble. What happens if you redeploy using an appropriate mechanism, such as Tomcat's manager app or Ant scripts? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deployment / war unpacking and Context definition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck; first off, thanks for the reply. [Caldarale, Charles R [EMAIL PROTECTED] @ Thu, 26 Apr 2007 09:36:38 -0500] Context path=/jdbclink reloadable=true Where is the above Context declaration? If it's anywhere other than in server.xml (where it shouldn't be), the path attribute must not be present. It lives inside the Host definition in server.xml, according to the example pointed out in http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html - - I already played around with adding and removing attributes like path and docPath without any obvious change for the better. Is there a better way to set this up? removing the webapps/jdbclink/ folder while the container is running doesn't make tomcat unpack / redeploy the .war file. Deleting arbitrary files out from under a running process is just asking for trouble. What happens if you redeploy using an appropriate mechanism, such as Tomcat's manager app or Ant scripts? I will have a look at the manager application then. By now I just deployed using the export-to-war facility of eclipse and relying upon tomcat to deploy the application as soon as the new war is there... ;) Anyhow, thanks and best regards, Kristian - -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGMLtccxBAPOA1m6wRAqZfAJ9twgr0thlgQRjsYtTour5o+I5ceACfcP71 mm+OTHAkncA/587mUJBlufw= =O2Ld -END PGP SIGNATURE-
RE: deployment / war unpacking and Context definition?
From: Kristian Rink [mailto:[EMAIL PROTECTED] Subject: Re: deployment / war unpacking and Context definition? It lives inside the Host definition in server.xml, according to the example pointed out in http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.h tml Unfortunately, several of the examples in the doc have not kept up with recommended practice for current versions of Tomcat. Placing the Context element in server.xml requires restarting Tomcat if any changes are required, which is why it's strongly discouraged these days. The Context element should be defined in META-INF/context.xml within the webapp structure; alternatively, it can be placed in conf/Catalina/[host]/[appName].xml if desired; the latter location will override the one in META-INF if both are present. The URI path is automatically determined by the name of the app's .war file. Look here for details: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html I wouldn't expect the presence of the Context element in server.xml to prevent redeployment, but you never can tell... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deployment / war unpacking and Context definition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck; [Caldarale, Charles R [EMAIL PROTECTED] @ Thu, 26 Apr 2007 09:56:45 -0500] changes are required, which is why it's strongly discouraged these days. The Context element should be defined in META-INF/context.xml within the webapp structure; alternatively, it can be placed in Thanks for pointing this out - this seems to have solved it, by now the .war both deploys again and the datasource is there for the context to use. Good to know getting it done this way is better (indeed messing with server.xml and restarting the container afterwards is a bad thing most of the time). Thanks for your help and bye, Kristian - -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGMMBWcxBAPOA1m6wRAiLHAJ93e0TfUCHC0LqTkDHjh94lH2IoYwCeLsIf aRhUOdZppg5nrdlIjJ61kCo= =6vlB -END PGP SIGNATURE-