RE: Setting properties outside of the WAR
How many properties do you want to set? i avoid the problem by one of 2 methods: i access my test db from test by port forwarding from 127.0.0.1. You could make it standard that the db should always be on a local IP/arbitrary port and leave it to the administrators to forward packets as they wish. Nice feature: the db link is on a by-machine basis, so subsequent releases don't need readjusting. method 2: use environment variables. You could use a properties file to provide defaults, write a wrapper which would replace defalts with calls to System.getProperty where there was one there. This doesn't handle multiple contexts on the same Vm very well, though, unless you get some sort of namespaces working. $TOMCAT_OPTS does something like this - ish in the startup script. Al -Original Message- From: Kitching Simon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 03, 2001 5:01 PM To: '[EMAIL PROTECTED]' Subject: RE: Setting properties outside of the WAR Hi Ritchie (and anyone else interested) Something else occurred to me after sending this email, and reading an unrelated email from Craig. Craig was talking about being able to run a webapp direct from a WAR file without unpacking it. Yes, the idea sounds nice, but then how is anyone to configure the webapp? The web.xml file can't be edited! This implies that the WAR is built with the necessary attributes already set, but isn't that like distributing a shrink-wrapped application with all the configuration items hard-wired and impossible to change by the end user??? Anyway, here's the perl script and a few related files. Documentation is in the comments inside "install.pl". The code may seem a little odd in places - the install program is a result of "experimenting" with various approaches, and not all the traces of previous experiments have been removed! install.pl install.cfg installTokensExample.cfg and here's an example of a file that will be modified during install: web.xml.install What I do to distribute an app is build a jar file containing the install.pl, install.cfg and installTokensExample.cfg files, and then a subdirectory containing the entire web application. To install a distribution the first time: * create an install directory, cd to it * Unjar the jar * cp installTokensExample.cfg ../installTokens.cfg (note rename) * vi ../installTokens.cfg and set specific attributes for that install * perl install.pl To upgrade a distribution, ie where a proper installTokens.cfg has already been created, * delete the old install directory * recreate the install directory, cd to it * unjar the new jar file * perl install.pl Any feedback welcome Cheers, Simon -Original Message- From: Ritchie Young [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 03, 2001 4:30 PM To: [EMAIL PROTECTED] Subject: Re: Setting properties outside of the WAR Oh good, it's not just me. Thanks, I would appreciate it if you did forward me a copy of that script. Cheers Ritchie - Original Message - From: "Kitching Simon" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 03, 2001 6:07 PM Subject: RE: Setting properties outside of the WAR I think that this whole issue (specifying configuration parameters to web applications) needs some serious thought - possibly at the level of the servlet spec development group, even. The problem is that two deployments of the same application are not necessarily identical. The most obvious example is where two otherwise identical installations need to be configured to use different databases (ie different JDBC connection strings). It is really **nasty** to deploy a webapp, then have to edit a string inside the WEB-INF/web.xml as part of the deployment procedure. (a) it's hard to describe in such a way that an "application support team" can reliably get it right, (b) if it is stuffed up, then really nasty consequences can occur - testing system gets connected to production database, or production system gets connected to development database, which is worse ???!! I think what is needed, instead, **is** some configuration outside of the webapp. Upgrading a webapp then doesn't "throw away" the configuration settings used for the previous release. Obviously, there needs to be some kind of consistency checking to ensure that new configuration items don't need to be added for the new release, etc. My current solution (which you are welcome to, Ritchie, if you want a copy) is a perl script which is run after installing a copy of the webapp. It searches the tree of files, replacing any occurrence of strings of form @token-name@ with a value from a property file which is specific to each *installation* of the webapp. My development installation of the webapp gets configured using one property file, my acceptance-test instance uses a second, and th
RE: Setting properties outside of the WAR
I think that this whole issue (specifying configuration parameters
to web applications) needs some serious thought - possibly
at the level of the servlet spec development group, even.
The problem is that two deployments of the same application are
not necessarily identical. The most obvious example is where two
otherwise identical installations need to be configured to use
different databases (ie different JDBC connection strings).
It is really **nasty** to deploy a webapp, then have to edit a string
inside the WEB-INF/web.xml as part of the deployment procedure.
(a) it's hard to describe in such a way that an "application support team"
can reliably get it right,
(b) if it is stuffed up, then really nasty consequences can occur
- testing system gets connected to production database, or
production system gets connected to development database,
which is worse ???!!
I think what is needed, instead, **is** some configuration
outside of the webapp. Upgrading a webapp then doesn't
"throw away" the configuration settings used for the previous
release. Obviously, there needs to be some kind of consistency
checking to ensure that new configuration items don't need to
be added for the new release, etc.
My current solution (which you are welcome to, Ritchie, if you
want a copy) is a perl script which is run after installing a copy
of the webapp. It searches the tree of files, replacing any occurrence
of strings of form @token-name@ with a value from a property file
which is specific to each *installation* of the webapp. My development
installation of the webapp gets configured using one property file,
my acceptance-test instance uses a second, and the production
system uses a third properties file.
While the *main* file that gets modified during the install is the
web.xml file, there are other files that get modified, eg the log4j
configuration options file which is also in WEB-INF.
Note that I do not want to use ANT to do this token-replacement
during building of the "WAR" file, because I want to have a standard
WAR file that can be deployed into development, testing and production.
Any alternatives that could be used to configure a webapp per-deployment
would be welcome - I'm not perfectly happy with my current solution, I just
can't think of anything better
Regards,
Simon
-Original Message-
From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, January 02, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Setting properties outside of the WAR
Ritchie Young wrote:
Thanks for the response but that wasn't quite what I was getting at.
The idea was that there should be some easy way for an administrator to
set
a property for the application. It just strikes me that the
TOMCAT_OPTIONS
variable is a slightly cumbersome way especially when there start to be
a
few more applications.
I thought that the "Context" tag in server.xml wouldn't be a bad place
to
incorporate application specific settings such as where the application
can
find it's properties file. This would also allow for multiple instance
of
the same application to use different configurations but only one WAR
file.
The settings in server.xml are designed to configure Tomcat's own features
--
not your application. Your app is responsible for that. You can do
things in a
portable way (for example, call
ServletContext.getResource("/WEB-INF/myprops.properties")), or not, as you
choose.
Keep in mind that the intent of web applications is that they are *stand
alone*
gadgets, to be dragged and dropped onto a servlet container (*any*
container,
not just Tomcat) and work correctly. Given that, it does not make sense
for the
servlet API to provide any mechanism to access resources outside of the
WAR.
You are free, of course, to implement any such technique (such as passing
the
absolute pathname to a properties file in a servlet initialization
parameter),
but you are making it harder on people who want to deploy your webapp in a
variety of environments, as well as limiting the set of environments in
which
your app can run (for example, an ISP might prohibit file access in order
to
protect the various web apps from each other).
Cheers
Ritchie
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Setting properties outside of the WAR
Oh good, it's not just me.
Thanks, I would appreciate it if you did forward me a copy of that script.
Cheers
Ritchie
- Original Message -
From: "Kitching Simon" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 03, 2001 6:07 PM
Subject: RE: Setting properties outside of the WAR
I think that this whole issue (specifying configuration parameters
to web applications) needs some serious thought - possibly
at the level of the servlet spec development group, even.
The problem is that two deployments of the same application are
not necessarily identical. The most obvious example is where two
otherwise identical installations need to be configured to use
different databases (ie different JDBC connection strings).
It is really **nasty** to deploy a webapp, then have to edit a string
inside the WEB-INF/web.xml as part of the deployment procedure.
(a) it's hard to describe in such a way that an "application support team"
can reliably get it right,
(b) if it is stuffed up, then really nasty consequences can occur
- testing system gets connected to production database, or
production system gets connected to development database,
which is worse ???!!
I think what is needed, instead, **is** some configuration
outside of the webapp. Upgrading a webapp then doesn't
"throw away" the configuration settings used for the previous
release. Obviously, there needs to be some kind of consistency
checking to ensure that new configuration items don't need to
be added for the new release, etc.
My current solution (which you are welcome to, Ritchie, if you
want a copy) is a perl script which is run after installing a copy
of the webapp. It searches the tree of files, replacing any occurrence
of strings of form @token-name@ with a value from a property file
which is specific to each *installation* of the webapp. My development
installation of the webapp gets configured using one property file,
my acceptance-test instance uses a second, and the production
system uses a third properties file.
While the *main* file that gets modified during the install is the
web.xml file, there are other files that get modified, eg the log4j
configuration options file which is also in WEB-INF.
Note that I do not want to use ANT to do this token-replacement
during building of the "WAR" file, because I want to have a standard
WAR file that can be deployed into development, testing and production.
Any alternatives that could be used to configure a webapp per-deployment
would be welcome - I'm not perfectly happy with my current solution, I
just
can't think of anything better
Regards,
Simon
-Original Message-
From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, January 02, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Setting properties outside of the WAR
Ritchie Young wrote:
Thanks for the response but that wasn't quite what I was getting at.
The idea was that there should be some easy way for an administrator
to
set
a property for the application. It just strikes me that the
TOMCAT_OPTIONS
variable is a slightly cumbersome way especially when there start to
be
a
few more applications.
I thought that the "Context" tag in server.xml wouldn't be a bad place
to
incorporate application specific settings such as where the
application
can
find it's properties file. This would also allow for multiple instance
of
the same application to use different configurations but only one WAR
file.
The settings in server.xml are designed to configure Tomcat's own
features
--
not your application. Your app is responsible for that. You can do
things in a
portable way (for example, call
ServletContext.getResource("/WEB-INF/myprops.properties")), or not, as
you
choose.
Keep in mind that the intent of web applications is that they are *stand
alone*
gadgets, to be dragged and dropped onto a servlet container (*any*
container,
not just Tomcat) and work correctly. Given that, it does not make sense
for the
servlet API to provide any mechanism to access resources outside of the
WAR.
You are free, of course, to implement any such technique (such as
passing
the
absolute pathname to a properties file in a servlet initialization
parameter),
but you are making it harder on people who want to deploy your webapp in
a
variety of environments, as well as limiting the set of environments in
which
your app can run (for example, an ISP might prohibit file access in
order
to
protect the various web apps from each other).
Cheers
Ritchie
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Setting properties outside of the WAR
Hi Ritchie (and anyone else interested) Something else occurred to me after sending this email, and reading an unrelated email from Craig. Craig was talking about being able to run a webapp direct from a WAR file without unpacking it. Yes, the idea sounds nice, but then how is anyone to configure the webapp? The web.xml file can't be edited! This implies that the WAR is built with the necessary attributes already set, but isn't that like distributing a shrink-wrapped application with all the configuration items hard-wired and impossible to change by the end user??? Anyway, here's the perl script and a few related files. Documentation is in the comments inside "install.pl". The code may seem a little odd in places - the install program is a result of "experimenting" with various approaches, and not all the traces of previous experiments have been removed! install.pl install.cfg installTokensExample.cfg and here's an example of a file that will be modified during install: web.xml.install What I do to distribute an app is build a jar file containing the install.pl, install.cfg and installTokensExample.cfg files, and then a subdirectory containing the entire web application. To install a distribution the first time: * create an install directory, cd to it * Unjar the jar * cp installTokensExample.cfg ../installTokens.cfg (note rename) * vi ../installTokens.cfg and set specific attributes for that install * perl install.pl To upgrade a distribution, ie where a proper installTokens.cfg has already been created, * delete the old install directory * recreate the install directory, cd to it * unjar the new jar file * perl install.pl Any feedback welcome Cheers, Simon -Original Message- From: Ritchie Young [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 03, 2001 4:30 PM To: [EMAIL PROTECTED] Subject: Re: Setting properties outside of the WAR Oh good, it's not just me. Thanks, I would appreciate it if you did forward me a copy of that script. Cheers Ritchie - Original Message - From: "Kitching Simon" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 03, 2001 6:07 PM Subject: RE: Setting properties outside of the WAR I think that this whole issue (specifying configuration parameters to web applications) needs some serious thought - possibly at the level of the servlet spec development group, even. The problem is that two deployments of the same application are not necessarily identical. The most obvious example is where two otherwise identical installations need to be configured to use different databases (ie different JDBC connection strings). It is really **nasty** to deploy a webapp, then have to edit a string inside the WEB-INF/web.xml as part of the deployment procedure. (a) it's hard to describe in such a way that an "application support team" can reliably get it right, (b) if it is stuffed up, then really nasty consequences can occur - testing system gets connected to production database, or production system gets connected to development database, which is worse ???!! I think what is needed, instead, **is** some configuration outside of the webapp. Upgrading a webapp then doesn't "throw away" the configuration settings used for the previous release. Obviously, there needs to be some kind of consistency checking to ensure that new configuration items don't need to be added for the new release, etc. My current solution (which you are welcome to, Ritchie, if you want a copy) is a perl script which is run after installing a copy of the webapp. It searches the tree of files, replacing any occurrence of strings of form @token-name@ with a value from a property file which is specific to each *installation* of the webapp. My development installation of the webapp gets configured using one property file, my acceptance-test instance uses a second, and the production system uses a third properties file. While the *main* file that gets modified during the install is the web.xml file, there are other files that get modified, eg the log4j configuration options file which is also in WEB-INF. Note that I do not want to use ANT to do this token-replacement during building of the "WAR" file, because I want to have a standard WAR file that can be deployed into development, testing and production. Any alternatives that could be used to configure a webapp per-deployment would be welcome - I'm not perfectly happy with my current solution, I just can't think of anything better Regards, Simon -Original Message- From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 02, 2001 10:10 PM To: [EMAIL PROTECTED] Subject: Re: Setting properties outside of the WAR Ritchie Young wrote: Thanks for the response but that wasn't quite w
Re: Setting properties outside of the WAR
Perhaps where this is going is a WebApp configurator that knew how to parse XML's , and could display the properties as a administrator-friendly menu, rather than a grisly collection of XML tags. The application might also be able to save a backup copy of configuration, and perhaps patch an older configuration to a new configuration -- and/or let you roll back if you screw something up. It could be used with any WebApp out-of-the-box, but there might also be extensions if developers "wrote to it". The Struts Digester utility might make a good backbone for something like this. Just an idea. (My plate's already full.-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Setting properties outside of the WAR
Kitching Simon wrote: I think that this whole issue (specifying configuration parameters to web applications) needs some serious thought - possibly at the level of the servlet spec development group, even. The best place to address your suggestions and comments in this regard is "[EMAIL PROTECTED]". The problem is that two deployments of the same application are not necessarily identical. The most obvious example is where two otherwise identical installations need to be configured to use different databases (ie different JDBC connection strings). The deployment descriptor approach is not unique to servlets and JSP pages -- it is consistent across all the components of a J2EE server. Most of the app server's I've seen offer some sort of "deployment tool" that lets you perform customizations like this as you deploy an application. Tomcat currently doesn't have such a thing. I think that would be a tremendously useful gadget to build. It would also solve (for Tomcat) the problems you describe below. It is really **nasty** to deploy a webapp, then have to edit a string inside the WEB-INF/web.xml as part of the deployment procedure. (a) it's hard to describe in such a way that an "application support team" can reliably get it right, (b) if it is stuffed up, then really nasty consequences can occur - testing system gets connected to production database, or production system gets connected to development database, which is worse ???!! I think what is needed, instead, **is** some configuration outside of the webapp. Upgrading a webapp then doesn't "throw away" the configuration settings used for the previous release. Obviously, there needs to be some kind of consistency checking to ensure that new configuration items don't need to be added for the new release, etc. My current solution (which you are welcome to, Ritchie, if you want a copy) is a perl script which is run after installing a copy of the webapp. It searches the tree of files, replacing any occurrence of strings of form @token-name@ with a value from a property file which is specific to each *installation* of the webapp. My development installation of the webapp gets configured using one property file, my acceptance-test instance uses a second, and the production system uses a third properties file. While the *main* file that gets modified during the install is the web.xml file, there are other files that get modified, eg the log4j configuration options file which is also in WEB-INF. Note that I do not want to use ANT to do this token-replacement during building of the "WAR" file, because I want to have a standard WAR file that can be deployed into development, testing and production. Any alternatives that could be used to configure a webapp per-deployment would be welcome - I'm not perfectly happy with my current solution, I just can't think of anything better Ah, you've just built your own custom "deploy tool" :-). A nice Swing-based GUI that did this kind of thing would sure be more pleasant. Regards, Simon Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Setting properties outside of the WAR
server's I've seen offer some sort of "deployment tool" that lets you perform customizations like this as you deploy an application. Off the top of my head, it seems that the right way to do it would be to specify a properties extension mechanism with more expressiveness than the simple context-param elements in the current web.xml. Right now, a good deployment tool could look into the war file and pull out the web.xml, inspect it for context-param elements and create a property sheet to set up those values. However, those properties would only be simple string name-value pairs, because there is no way to specify anything like constraints or non-string types. Hmm, perhaps the resource-ref element could be pressed into service. Basically if you had a tag that pointed to a Bean class you could define custom property editors for manipulating the properties of that class. s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Setting properties outside of the WAR
Thanks for the response but that wasn't quite what I was getting at.
The idea was that there should be some easy way for an administrator to set
a property for the application. It just strikes me that the TOMCAT_OPTIONS
variable is a slightly cumbersome way especially when there start to be a
few more applications.
I thought that the "Context" tag in server.xml wouldn't be a bad place to
incorporate application specific settings such as where the application can
find it's properties file. This would also allow for multiple instance of
the same application to use different configurations but only one WAR file.
Cheers
Ritchie
To set properties dynamically in your application you can try this command
java.lang.System.setProperty(key,value)
Or
System.getProperties().put("HTTPClient.dontChunkRequests", "true");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
