Re: Context.xml not updating dataSource
On Monday 20 July 2009 17:08:15 Mike Frohme wrote: Edit the copy of the context.xml file and all will work as you expect. 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. A an aside, wouldn't it be nice if it were configurable whether tomcat copies the context.xml to $CATALINA_BASE/conf? Then administrators could decide to never have local configuration and always rely on the config within the war? Sorry for the late reply, Rainer. There is, in principle. Set deployXML to false in the Host declaration in your server.xml and it will do exactly what you want. On the flip side, tomcat will remove the configuration when the app is undeployed, so you need a little care in your deployment process. Thanks for the response. Actually, doesn't this do the exact oposite of what I want? What I want (as option): I know that developer/packager did it right and I never want to have local configuration. Always use the context.xml within the currently deployed application, updated every time I redeploy the app. deployXML=false seems to do: Never trust the developer, don't even copy their context configuration to local configuration if there is no local one yet. Only use a configuration I manually put on the server. Could anyone please comment whether I understand that right? Mike Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
Rainer Frey wrote: On Monday 20 July 2009 17:08:15 Mike Frohme wrote: Edit the copy of the context.xml file and all will work as you expect. 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. A an aside, wouldn't it be nice if it were configurable whether tomcat copies the context.xml to $CATALINA_BASE/conf? Then administrators could decide to never have local configuration and always rely on the config within the war? Sorry for the late reply, Rainer. There is, in principle. Set deployXML to false in the Host declaration in your server.xml and it will do exactly what you want. On the flip side, tomcat will remove the configuration when the app is undeployed, so you need a little care in your deployment process. Thanks for the response. Actually, doesn't this do the exact oposite of what I want? What I want (as option): I know that developer/packager did it right and I never want to have local configuration. Always use the context.xml within the currently deployed application, updated every time I redeploy the app. deployXML=false seems to do: Never trust the developer, don't even copy their context configuration to local configuration if there is no local one yet. Only use a configuration I manually put on the server. Could anyone please comment whether I understand that right? You do. In which case, undeploy your application before you deploy the new version and Tomcat will remove the copied context.xml as part of the undeployment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context.xml not updating dataSource
Sorry, Rainer - I didn't read your msg carefully, and Mark's word is right on. Others will clarify, but as I understand it ... The default Host attribute is deployXML true which means that the context.xml is deployed to conf/[engine]/[host]/appname.xml on application deployment, and undeployed appropriately. Mark's comment to undeploy your application before you deploy the new version and Tomcat will remove the copied context.xml as part of the undeployment. is important - you may find that you are using an old context.xml if the app is not undeployed cleanly - that may have led to your original comment, I don't recall. If deployXML is false, your infrastructure team, or container/instance owner is responsible for maintaining resource contexts on applications' behalf - the case where backend security is a little more an issue, or the developer doesn't really know best. Undeploying the application in this case *removes* the conf/[engine]/[host]/appname.xml, requiring manual/process intervention to restore it. Apologies for the confusion. -- Mike -Original Message- From: Rainer Frey [mailto:rainer.f...@inxmail.de] Sent: Tuesday, July 21, 2009 2:40 AM To: Tomcat Users List Subject: Re: Context.xml not updating dataSource On Monday 20 July 2009 17:08:15 Mike Frohme wrote: Edit the copy of the context.xml file and all will work as you expect. 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. A an aside, wouldn't it be nice if it were configurable whether tomcat copies the context.xml to $CATALINA_BASE/conf? Then administrators could decide to never have local configuration and always rely on the config within the war? Sorry for the late reply, Rainer. There is, in principle. Set deployXML to false in the Host declaration in your server.xml and it will do exactly what you want. On the flip side, tomcat will remove the configuration when the app is undeployed, so you need a little care in your deployment process. Thanks for the response. Actually, doesn't this do the exact oposite of what I want? What I want (as option): I know that developer/packager did it right and I never want to have local configuration. Always use the context.xml within the currently deployed application, updated every time I redeploy the app. deployXML=false seems to do: Never trust the developer, don't even copy their context configuration to local configuration if there is no local one yet. Only use a configuration I manually put on the server. Could anyone please comment whether I understand that right? Mike Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context.xml not updating dataSource
Sorry for the late reply, Rainer. There is, in principle. Set deployXML to false in the Host declaration in your server.xml and it will do exactly what you want. On the flip side, tomcat will remove the configuration when the app is undeployed, so you need a little care in your deployment process. -- Mike -Original Message- From: Rainer Frey [mailto:rainer.f...@inxmail.de] Sent: Tuesday, June 23, 2009 3:07 AM To: Tomcat Users List Subject: Re: Context.xml not updating dataSource On Monday 22 June 2009 13:53:47 Mark Thomas wrote: Edit the copy of the context.xml file and all will work as you expect. 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. A an aside, wouldn't it be nice if it were configurable whether tomcat copies the context.xml to $CATALINA_BASE/conf? Then administrators could decide to never have local configuration and always rely on the config within the war? Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
On Monday 22 June 2009 13:53:47 Mark Thomas wrote: Edit the copy of the context.xml file and all will work as you expect. 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. A an aside, wouldn't it be nice if it were configurable whether tomcat copies the context.xml to $CATALINA_BASE/conf? Then administrators could decide to never have local configuration and always rely on the config within the war? Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
Francis Judge wrote: I am using Tomcat 6.0.18 and am using jTDS to connect to SQL Server 2005. The application is working fine in development (I'm using Netbeans 6.5) and I build the WAR from the IDE at the moment. When I deploy the WAR to the test server How do you deploy your WAR? Is unpackWARs true or false? I update the context.xml to point the database Exactly which file do you edit? connection URL to the testing SQL Server, and restart the application server. But, the DataSource is still using the settings from the WAR that I deployed and not reading the new values that I changed in the context.xml. If I put the testing details into the context.xml before I build the WAR then they are the ones used and everything works correctly. Surely this is not how Tomcat is intended to behave? It may not be how you intended Tomcat to behave. How Tomcat should behave will depend on the answers to the questions above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
I'm editing the context.xml in the application's MET-INF directory. The following is what it contains: Resource name=*DB/TMS* auth=*Container* type=*javax.sql.DataSource* username=* password=* driverClassName=*net.sourceforge.jtds.jdbcx.JtdsDataSource* url=*jdbc:jtds:sqlserver://localhost:1433;DatabaseName=TMS* maxActive=*8* maxIdle=*1* removeAbandoned=*true* I have not set the 'unpackWARs' option anywhere but I deploy through the tomcat administrative console. Mark Thomas wrote: Francis Judge wrote: I am using Tomcat 6.0.18 and am using jTDS to connect to SQL Server 2005. The application is working fine in development (I'm using Netbeans 6.5) and I build the WAR from the IDE at the moment. When I deploy the WAR to the test server How do you deploy your WAR? Is unpackWARs true or false? I update the context.xml to point the database Exactly which file do you edit? connection URL to the testing SQL Server, and restart the application server. But, the DataSource is still using the settings from the WAR that I deployed and not reading the new values that I changed in the context.xml. If I put the testing details into the context.xml before I build the WAR then they are the ones used and everything works correctly. Surely this is not how Tomcat is intended to behave? It may not be how you intended Tomcat to behave. How Tomcat should behave will depend on the answers to the questions above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
Francis Judge wrote: I'm editing the context.xml in the application's MET-INF directory. The following is what it contains: Resource name=*DB/TMS* auth=*Container* type=*javax.sql.DataSource* username=* password=* driverClassName=*net.sourceforge.jtds.jdbcx.JtdsDataSource* url=*jdbc:jtds:sqlserver://localhost:1433;DatabaseName=TMS* maxActive=*8* maxIdle=*1* removeAbandoned=*true* I have not set the 'unpackWARs' option anywhere but I deploy through the tomcat administrative console. You are editing the wrong file. When a web application is first deployed, any META-INF/context.xml is copied to CATALINA_BASE/conf/enginename/hostname (usually CATALINA_BASE/conf/Catalina/localhost) and renamed to appName.xml. Eg for a war file named myapp.war a META-INF/context.xml would be renamed to myapp.xml# Edit the copy of the context.xml file and all will work as you expect. Mark Mark Thomas wrote: Francis Judge wrote: I am using Tomcat 6.0.18 and am using jTDS to connect to SQL Server 2005. The application is working fine in development (I'm using Netbeans 6.5) and I build the WAR from the IDE at the moment. When I deploy the WAR to the test server How do you deploy your WAR? Is unpackWARs true or false? I update the context.xml to point the database Exactly which file do you edit? connection URL to the testing SQL Server, and restart the application server. But, the DataSource is still using the settings from the WAR that I deployed and not reading the new values that I changed in the context.xml. If I put the testing details into the context.xml before I build the WAR then they are the ones used and everything works correctly. Surely this is not how Tomcat is intended to behave? It may not be how you intended Tomcat to behave. How Tomcat should behave will depend on the answers to the questions above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
Brilliant, I didn't see this in any of the documentation that read. Thanks for the help Francis Mark Thomas wrote: Francis Judge wrote: I'm editing the context.xml in the application's MET-INF directory. The following is what it contains: Resource name=*DB/TMS* auth=*Container* type=*javax.sql.DataSource* username=* password=* driverClassName=*net.sourceforge.jtds.jdbcx.JtdsDataSource* url=*jdbc:jtds:sqlserver://localhost:1433;DatabaseName=TMS* maxActive=*8* maxIdle=*1* removeAbandoned=*true* I have not set the 'unpackWARs' option anywhere but I deploy through the tomcat administrative console. You are editing the wrong file. When a web application is first deployed, any META-INF/context.xml is copied to CATALINA_BASE/conf/enginename/hostname (usually CATALINA_BASE/conf/Catalina/localhost) and renamed to appName.xml. Eg for a war file named myapp.war a META-INF/context.xml would be renamed to myapp.xml# Edit the copy of the context.xml file and all will work as you expect. Mark Mark Thomas wrote: Francis Judge wrote: I am using Tomcat 6.0.18 and am using jTDS to connect to SQL Server 2005. The application is working fine in development (I'm using Netbeans 6.5) and I build the WAR from the IDE at the moment. When I deploy the WAR to the test server How do you deploy your WAR? Is unpackWARs true or false? I update the context.xml to point the database Exactly which file do you edit? connection URL to the testing SQL Server, and restart the application server. But, the DataSource is still using the settings from the WAR that I deployed and not reading the new values that I changed in the context.xml. If I put the testing details into the context.xml before I build the WAR then they are the ones used and everything works correctly. Surely this is not how Tomcat is intended to behave? It may not be how you intended Tomcat to behave. How Tomcat should behave will depend on the answers to the questions above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
On Monday 22 June 2009 12:02:49 Mark Thomas wrote: You are editing the wrong file. When a web application is first deployed, any META-INF/context.xml is copied to CATALINA_BASE/conf/enginename/hostname (usually CATALINA_BASE/conf/Catalina/localhost) and renamed to appName.xml. Eg for a war file named myapp.war a META-INF/context.xml would be renamed to myapp.xml# Edit the copy of the context.xml file and all will work as you expect. What is the reason for this behavior? It seems quite counterintuitive. If I package a new version of my application with updated configuration, I usually expect that this configuration is used when I deploy this application, esp. with the manager deployment functionality. If I want to deploy the application on different tomcat installations, I have to delete the file from CATALINA_BASE/conf on each one, and it even might have a different path on each. So this behavior causes more work for my use case, and I have to do s.th. in addition to the standard deployment call. Is there a benefit from it? Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
Rainer Frey wrote: On Monday 22 June 2009 12:02:49 Mark Thomas wrote: You are editing the wrong file. When a web application is first deployed, any META-INF/context.xml is copied to CATALINA_BASE/conf/enginename/hostname (usually CATALINA_BASE/conf/Catalina/localhost) and renamed to appName.xml. Eg for a war file named myapp.war a META-INF/context.xml would be renamed to myapp.xml# Edit the copy of the context.xml file and all will work as you expect. What is the reason for this behavior? It seems quite counterintuitive. If I package a new version of my application with updated configuration, I usually expect that this configuration is used when I deploy this application, esp. with the manager deployment functionality. If I want to deploy the application on different tomcat installations, I have to delete the file from CATALINA_BASE/conf on each one, and it even might have a different path on each. So this behavior causes more work for my use case, and I have to do s.th. in addition to the standard deployment call. Is there a benefit from it? 1. In production, the operations folks don't have to unpack the app, edit the context file and re-pack the app to edit the configuration. 2. When a new version of the app is installed, the environment specific configuration isn't lost. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml not updating dataSource
On Monday 22 June 2009 13:53:47 Mark Thomas wrote: Rainer Frey wrote: On Monday 22 June 2009 12:02:49 Mark Thomas wrote: You are editing the wrong file. When a web application is first deployed, any META-INF/context.xml is copied to CATALINA_BASE/conf/enginename/hostname (usually CATALINA_BASE/conf/Catalina/localhost) and renamed to appName.xml. Eg for a war file named myapp.war a META-INF/context.xml would be renamed to myapp.xml# Edit the copy of the context.xml file and all will work as you expect. If I want to deploy the application on different tomcat installations, I have to delete the file from CATALINA_BASE/conf on each one, and it even might have a different path on each. If you want to remove the old configuration, undeploy the app first which will remove the old configuration file. Thanks, this was the point I missed. Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
