3

A lot of the advice on the web on storing variables which may change depending on the env/other conditions is to put them in web.xml, but isn't the web.xml within the war file? even if you find the exploded war and change it, wouldn't it get overriden if you update the war file? Or does the webcontainer provide any method to configure the web.xml without tinkering with the war file?

Rnet
  • 4,796
  • 9
  • 47
  • 83
  • 2
    The irony of Enterprise Configuration: Make a complex framework for the configuration which reads from an XML file because "it shouldn't be hardcoded since maybe you want to change it without rebuilding the whole thing", then you spec it so that you have to make a new artifact whenever you need to reconfigure something. The lolz. – gustafc Jun 14 '13 at 14:36
  • @gustafc exactly, it seems we always need just one more abstraction layer – Rnet Jun 14 '13 at 14:43

4 Answers4

3

The web.xml variables are of very limited use, in my experience - the only advantage is that it's a standard location to look for hard-coded "configuration".

There are several common solutions to get a more sensible way to configure web apps, none of which is standard:

  • Use system properties (which usually involves fiddling around with startup scripts, and it can be hard to get a good overview of your entire config)
  • Use environment variables (same drawbacks as system properties)
  • Read a config file from a predefined location; often from the classpath by using getResourceAsStream (IIRC that usually means putting the config files in Tomcat's lib directory)

You can also use JNDI, which has the disadvantage of being rather heavy-weight both to set up and read (if you're using vanilla Java, anyways - Spring for example has rather good support for reading from JNDI). However, JNDI is rather good because it's per-application, and not a process-global setting. If you need to run several instances of the same app on the same server, JNDI is pretty much the only option (although you can use it to just point out a config file somewhere, which makes things easier to work with).

This may be relevant to your interests: How can I store Java EE configuration parameters outside of an EAR or WAR?

Community
  • 1
  • 1
gustafc
  • 28,465
  • 7
  • 73
  • 99
  • Using JNDI to locate a constant file makes sense. Googling tomcat+jndi config shows results which put jndi config inside web.xml env-entry or META-INF/context.xml, I know that's the not the only way to do it, but still, The lolz. – Rnet Jun 14 '13 at 15:17
0

Advantages of specifying Parameter Values in web.xml

  • Using your own settings file requires additional coding and management.
  • Hard-coding parameter values directly into your application code makes them more difficult to change in the future, and more difficult to use different settings for different deployments (eg: JDBC settings, mail server address).
  • Other developers using your code will be able to find any relevant parameters more easily, as this is a standard location for such parameters to be set.

See also:

Community
  • 1
  • 1
Rong Nguyen
  • 4,143
  • 5
  • 27
  • 53
  • All the points can also be applied to a xyzConstants.java file which just declares all the constants as static Strings etc, how is web.xml declaration better than a constants file? – Rnet Jun 14 '13 at 14:47
  • @Rnet You can inherit and override them. – Rong Nguyen Jun 14 '13 at 14:49
0

As far as I know web.xml does not provide ability to store custom variables. Typical way to configure your web application is to store configuration in database, separate properties/xml/json/other file, get configuration from separate web service or provide it through environment variables.

Often a mixture of all these is used. For example you can add system variable using -D switch when running your container. This variable will contain path to file or URL where your configuration can be found.

You can supply parameters using OS environment.

You choice should depend on how many parameters do you have, what kind of application are you developing and how can you configure application server or computer OS. For example if you a hosting application on server you cannot configure these ways are not for you, so DB or web service are your only ways.

AlexR
  • 114,158
  • 16
  • 130
  • 208
  • Yes, I may not be able to access OS env variables on production, even if I did, it can be easily changed by any other application, script etc. DB/web service is a luxury which small applications may not have. System variable -D might work, but doesn't seem clean it feels like enforcing something on the whole server startup cause of your webapp, if there are lots of webapps in the same server and each one specifies many variables it gets messy fast. – Rnet Jun 14 '13 at 14:41
0

The folks that work on the Tomcat container recognize the irony that you have identified and have implemented a way to work-around the issue.

The solution that they implemented for the issues that you have alluded to is to create another xml file... the context.xml file, which is read by the server.

It appears that you can edit this file and have the new values read by the Tomcat without a restart... as long as you keep the elements out of the server.xml.

I do not use Tomcat so I might be mis-interpreting the docs

The GlassFish web container supports a similar feature, but does it via a couple admin cli command (asadmin):

There is probably web admin console support and you can set them up by editing the domain.xml. It seems like it isn't as flexible as the Tomcat implementation... but it does make it really easy to use.

You need to disable and then enable your application for the changed values to 'take'. Do not redeploy you app, since that will delete the value that you just set.

vkraemer
  • 9,864
  • 2
  • 30
  • 44