Re: Convenient web application configuration.
My end solution ended up being to modify $CATALINA_ROOT/conf/context.xml and put the JNDI data source definition there. While I agree that modifying global server files is less than ideal it is by far the simplest solution: It's only one resource element that has to be added, it requires no modification to deployment scripts, and solves the problem of site-specific data source. I left non site-specific servlet context configuration in each servlet's web.xml. Then, I moved site-specific servlet context parameters into the database. This ended up working out really nicely for a number of reasons. Everything is much more convenient now. Thanks for all your advice. Jason On Tue, Nov 4, 2008 at 5:15 PM, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, Jason Cipriani wrote: I'm developing with Eclipse but could configure custom build steps with ant. This solution would remove most of the inconvenience, but I would still have to make 4 separate WARs available for distribution. Not *too* big of a deal but I'd rather just distribute a single archive. If you need a different web.xml file for each machine, they you will, by definition, require a different WAR for each machine. There's really nothing you can do about that. Another option would be to configure your application using something other than web.xml but then you've just moved the problem to another file. We use a file in the user's home directory (called .ant.properties) that includes machine-specific environmental information. To deploy, we grab the source from CVS and run ant install which does everything, including merging the machine-specific configuration into the WAR and deploying it. We have a small number of production machines, so this isn't a big deal for us. If we had a large number, we'd just further script the process by allowing the WAR creation to be parameterized by, say, command-line switches (which they really are, since you can define any ant property right on the command-line). Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkQyYEACgkQ9CaO5/Lv0PBzXQCdH4lqz0vHbGOChbEJIihowz50 2lsAoK6obiLTx09nSb7+8taZxxITlpjM =GAv3 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Convenient web application configuration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, Jason Cipriani wrote: My end solution ended up being to modify $CATALINA_ROOT/conf/context.xml and put the JNDI data source definition there. Yikes! You should /definitely/ not do that. Doing so will make that JNDI data source available (separately, I might add) to all deployed applications. You'd be better off putting it in server.xml, since nobody really ever looks for anything in the server-wide context.xml. I believe you will be adding confusion at the least and a management nightmare at the worst. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkTbmgACgkQ9CaO5/Lv0PBg4gCgpjHTTBCbQDvesDsgYh7ork8i 11YAn2d/Hx2erPtBGBdxrkVjLwAY97Wr =4mqt -END PGP SIGNATURE- - 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: Convenient web application configuration.
Hmm, well, there are no other web applications, the server is dedicated to this one. If there *were* other web applications, they would likely be using the same data source anyways -- and in that case it's certainly handy to be able to set the data source for multiple web apps by maintaining just a single entry in one of Tomcat's configuration files. Also, for now, I did name the resource something unique to the web application, I'm not worried about conflicts. As for management, simple instructions insert this into context.xml on new server setup seems to be working out well. I can't think of any way that's more convenient. IMHO, if the choice is writing custom deployment scripts and having to maintain and run those to deploy the web app (and centrally maintaining separate copies of configuration files so they can be distributed with the deployment scripts rather than letting other developers maintain their own), and describe to other developers how those work vs. adding an entry to context.xml once and using Tomcat manager to deploy things, it seems that the former ends up being more confusing and hard to manage. To be honest I can't think of a single compelling reason not to do it this way, or any reason at all other than the fact that I have to explain to developers that when setting up a new system, they must modify Tomcat configuration files, and I don't see that as a big deal. I could be missing something, but everything is working great and is incredibly easy to manage now that I've made this change. That seems positive. Jason On Thu, Nov 6, 2008 at 5:23 PM, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, Jason Cipriani wrote: My end solution ended up being to modify $CATALINA_ROOT/conf/context.xml and put the JNDI data source definition there. Yikes! You should /definitely/ not do that. Doing so will make that JNDI data source available (separately, I might add) to all deployed applications. You'd be better off putting it in server.xml, since nobody really ever looks for anything in the server-wide context.xml. I believe you will be adding confusion at the least and a management nightmare at the worst. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkTbmgACgkQ9CaO5/Lv0PBg4gCgpjHTTBCbQDvesDsgYh7ork8i 11YAn2d/Hx2erPtBGBdxrkVjLwAY97Wr =4mqt -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Convenient web application configuration.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason, Jason Cipriani wrote: I'm developing with Eclipse but could configure custom build steps with ant. This solution would remove most of the inconvenience, but I would still have to make 4 separate WARs available for distribution. Not *too* big of a deal but I'd rather just distribute a single archive. If you need a different web.xml file for each machine, they you will, by definition, require a different WAR for each machine. There's really nothing you can do about that. Another option would be to configure your application using something other than web.xml but then you've just moved the problem to another file. We use a file in the user's home directory (called .ant.properties) that includes machine-specific environmental information. To deploy, we grab the source from CVS and run ant install which does everything, including merging the machine-specific configuration into the WAR and deploying it. We have a small number of production machines, so this isn't a big deal for us. If we had a large number, we'd just further script the process by allowing the WAR creation to be parameterized by, say, command-line switches (which they really are, since you can define any ant property right on the command-line). Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkQyYEACgkQ9CaO5/Lv0PBzXQCdH4lqz0vHbGOChbEJIihowz50 2lsAoK6obiLTx09nSb7+8taZxxITlpjM =GAv3 -END PGP SIGNATURE- - 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: Convenient web application configuration.
Jason Cipriani [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I'm using Tomcat 6.0.18 on Windows XP SP3, Windows Server 2003, and
Windows Vista (UAC disabled).
I have a web application with a lot of configuration options, all
currently stored as servlet initialization parameters in
WEB-INF/web.xml. The parameters are site specific and are different
for my development machine, the machines of the two other developers
working on the project, and the production machine. I am the only
developer working on the web application.
My problem is that web.xml is part of the web application WAR file.
Also web.xml differs for the 4 different machine the web application
runs on. This means that every single time I make a release, I have to
comment and uncomment blocks of parameters in web.xml, build 4
separate WAR files customized for each machine, and make the 4
separate WAR files available to each of the 4 people running the web
application. This is very cumbersome and it seems unreasonably
complicated, and has already led to a number of distribution mistakes
on multiple occasions. Is there a better place I can store
site-specific configuration options? Any suggestions would be helpful.
This is specific to Tomcat, but Tomcat will do System variable replacement
while parsing web.xml. So you would do something like:
init-param
param-namefoobar/param-name
param-value${myapp.foobar}/param-value
/init-param
Then each of the 4 just have to include a -Dmyapp.foobar=value when starting
up Tomcat.
Similarly, I have a JDBC data source defined in META-INF/context.xml.
The data source parameters are different for each machine. Is there
some other way I can define data sources so that I don't have to
maintain separate WAR files for each configuration?
Ideally I'd be able to put the settings in context.xml and web.xml
somewhere outside of the web application directory, and leave them out
of the web-app's local files, and so they wouldn't have to be packaged
with the WAR and deploying the WAR wouldn't blow away existing
configuration data.
Thanks,
Jason
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Convenient web application configuration.
I'm using Tomcat 6.0.18 on Windows XP SP3, Windows Server 2003, and Windows Vista (UAC disabled). I have a web application with a lot of configuration options, all currently stored as servlet initialization parameters in WEB-INF/web.xml. The parameters are site specific and are different for my development machine, the machines of the two other developers working on the project, and the production machine. I am the only developer working on the web application. My problem is that web.xml is part of the web application WAR file. Also web.xml differs for the 4 different machine the web application runs on. This means that every single time I make a release, I have to comment and uncomment blocks of parameters in web.xml, build 4 separate WAR files customized for each machine, and make the 4 separate WAR files available to each of the 4 people running the web application. This is very cumbersome and it seems unreasonably complicated, and has already led to a number of distribution mistakes on multiple occasions. Is there a better place I can store site-specific configuration options? Any suggestions would be helpful. Similarly, I have a JDBC data source defined in META-INF/context.xml. The data source parameters are different for each machine. Is there some other way I can define data sources so that I don't have to maintain separate WAR files for each configuration? Ideally I'd be able to put the settings in context.xml and web.xml somewhere outside of the web application directory, and leave them out of the web-app's local files, and so they wouldn't have to be packaged with the WAR and deploying the WAR wouldn't blow away existing configuration data. Thanks, Jason - 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: Convenient web application configuration.
From: Jason Cipriani [mailto:[EMAIL PROTECTED] Subject: Convenient web application configuration. Is there a better place I can store site-specific configuration options? Read the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Context%20Parameters Is there some other way I can define data sources so that I don't have to maintain separate WAR files for each configuration? The Resource element must go inside a Context element, but you can place the Context in conf/Catalina/[host]/[appName].xml rather than in the webapp's META-INF/context.xml file. Again, read the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction Your deployment script will need to copy the site-specific file containing your Context element to conf/Catalina/[host]/[appName].xml since that file is removed when a webapp is undeployed. - 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: Convenient web application configuration.
jason cipriani-2 wrote: Ideally I'd be able to put the settings in context.xml and web.xml somewhere outside of the web application directory, and leave them out of the web-app's local files, and so they wouldn't have to be packaged with the WAR and deploying the WAR wouldn't blow away existing configuration data. Jason, The easiest way is to place Context and the different Resource elements into each Tomcat's server.xml file. Someone will tell you that it's not recommended, but it will just work. Hope it helps, br1 -- View this message in context: http://www.nabble.com/Convenient-web-application-configuration.-tp20244034p20252816.html Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: Convenient web application configuration.
From: br1 [mailto:[EMAIL PROTECTED] Subject: Re: Convenient web application configuration. The easiest way is to place Context and the different Resource elements into each Tomcat's server.xml file. Certainly not easiest by any definition of the term that I'm familiar with, especially in a production environment. Immediately obvious drawbacks: 1) Restart of Tomcat (not just the webapp) required when *any* changes are needed. 2) Sysadmins don't like app developers mucking with server configurations. 3) Doesn't bundle the webapp-specific configuration with the webapp. 4) Error prone due to the manual editing required. - 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: Convenient web application configuration.
On Thu, Oct 30, 2008 at 8:22 AM, Pid [EMAIL PROTECTED] wrote: Is your build process automated, say with ant or maven? If so, it should be a relatively simple one-off job to configure multiple output war files from one codebase with several configurations. I'm developing with Eclipse but could configure custom build steps with ant. This solution would remove most of the inconvenience, but I would still have to make 4 separate WARs available for distribution. Not *too* big of a deal but I'd rather just distribute a single archive. On Thu, Oct 30, 2008 at 9:44 AM, Caldarale, Charles R [EMAIL PROTECTED] wrote: Read the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Context%20Parameters ... The Resource element must go inside a Context element, but you can place the Context in conf/Catalina/[host]/[appName].xml rather than in the webapp's META-INF/context.xml file. Again, read the doc: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction Your deployment script will need to copy the site-specific file containing your Context element to conf/Catalina/[host]/[appName].xml since that file is removed when a webapp is undeployed. Thanks for the advice and the doc link, this looks like the best option. I was deploying the WAR through the Tomcat manager, I'll have to change that (unless there's a way to configure custom deployment steps through the manager?). Is there a way to keep it from being removed when the app is undeployed? On Thu, Oct 30, 2008 at 2:32 PM, br1 [EMAIL PROTECTED] wrote: The easiest way is to place Context and the different Resource elements into each Tomcat's server.xml file. Someone will tell you that it's not recommended, but it will just work. That's not a bad idea, except it seems I can get around all of the drawbacks Chuck mentioned with the low cost of putting the file in conf/Catalina/[host]/[appName].xml instead. Although it's enticing, since it's something I'd only have to set up once per server and not think about again. For now this server is dedicated to a single web application so restarting the server is not any worse than restarting the web app. Thanks for your replies, Jason - 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: Convenient web application configuration.
Jason Cipriani wrote: I have a web application with a lot of configuration options, all currently stored as servlet initialization parameters in WEB-INF/web.xml. The parameters are site specific and are different for my development machine, the machines of the two other developers working on the project, and the production machine. I am the only developer working on the web application. There's one conceptual issue you'll need to look at, namely that of separation the environment-dependent configuration from the environment-independent one. At the first, making the distinction between the two can be problematic, and there may well be bordercases - those you'll just need to decide. With this strategy, I have applications that I can move trhough the chain from development to testing to production without touching the .war file contents -- and it's very rare to have a situation where an application change would require a change in the environment-dependent configuration. Similarly, I have a JDBC data source defined in META-INF/context.xml. The data source parameters are different for each machine. Is there some other way I can define data sources so that I don't have to maintain separate WAR files for each configuration? Take the context.xml out of the webapp; it wasn't meant to be there. With Tomcat, conf/Catalina/[hostname]/[appname].xml is a better place. If there's something you can't place in that file, at least create a variable in context.xml that does point to the external resource (file, server, whatever). If you have multiple applications dependent on some single, poolable resource (common database schema, for example), it would be better to place the JDBC datasource definition into server.xml, and put instead a ResourceLink element into each of the per-application context.xml files. That way, you'll have a single pool serving the various applications (this of course requires that all the applications play fair and do not leak; a sinlge leaky application can starve other applications by hogging all instances of a shared resource. Ideally I'd be able to put the settings in context.xml and web.xml somewhere outside of the web application directory, and leave them out of the web-app's local files, and so they wouldn't have to be packaged with the WAR and deploying the WAR wouldn't blow away existing configuration data. web.xml can also be configurable -- but leave there the aspects of configuration you'd otherwise put as fixed parameters into your source code, to be determined at compile time. -- ..Juha - 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: Convenient web application configuration.
Hi, Caldarale, Charles R wrote: From: br1 [mailto:[EMAIL PROTECTED] Subject: Re: Convenient web application configuration. The easiest way is to place Context and the different Resource elements into each Tomcat's server.xml file. Certainly not easiest by any definition of the term that I'm familiar with, especially in a production environment. It probably depends on requirements. I am familiar calling it the easiest and I manage production environments. Caldarale, Charles R wrote: 1) Restart of Tomcat (not just the webapp) required when *any* changes are needed. It just takes a few seconds, and *any* change is done first in the development environment. When the test environment is happy, the production one is just restarted once. Also, do you mean deploy a webapp under Windows without restarting Tomcat? Caldarale, Charles R wrote: 2) Sysadmins don't like app developers mucking with server configurations. Absolutely! I did not mean this at all. I mean that some sysadmins are happy to waste their time to fix these details themselves for exactly this reason. And they don't like app developers deciding the app path, nor they like app developers decide where their log files should go or where, for instance, a full text index should stay. The list is long, and no one forgot database connections. Caldarale, Charles R wrote: 3) Doesn't bundle the webapp-specific configuration with the webapp. Making the webapp point to a development or production database is not specific to the webapp at all. It is specific to the environment (the context) that the webapp is running on. Same applies to other resources as I mentioned above. Another reason you want to do it: you want connection pooling at the Tomcat instance level, and you use a global JNDI resource, that means edit the server.xml. (Thunder here) Caldarale, Charles R wrote: 4) Error prone due to the manual editing required. - Chuck Just like any other file the sysadmin edits.. also see point (1). In no case I was suggesting an app developer to edit files, other than the development environment. br1 -- View this message in context: http://www.nabble.com/Convenient-web-application-configuration.-tp20244034p20256710.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
