5

I have a customer who wants the ability to modify the .properties files packaged in the web applications WAR file so that they have the control to modify environments at settings. They will be hosting this site on their own servers so I can't say I blame them but I am a little unsure what the best course is.

I would think that any adminstrator of a Java EE application server should know how to drill into the WAR package with a zip tool and find and modify the properties files themselves. I am unsure if this is common knowledge or not.

I have typically always packaged my build artifacts with the property files appropriate for a given environment, but this is kind of an oddball case where WE build the WAR and hand it off to the customer. I might try to keep the property files external from the WAR but then it gets messy because of classloader issues (JBoss classloader, Tomcat classloader, etc...)

I am thinking that as a convenience we maintain properties files for THEIR environments and change and build these on their requests. My manager likes this idea because it keeps us in control but the customer doesn't like this.

What would you do?

|improve this question
  • Update: My boss had a meeting with the customer and we are going to give them a preconfigured WAR file for their environment. We will also be available to rebuild for them if their environments change, and we will provide instructions to SAFELY (shut down the server first) locate and modify the properties files. They verbally acknowledged we are not liable IF they do this. Thanks for the help, the answers were informative. – maple_shaft♦ Jul 13 '11 at 17:03
7

Q: What can the properties change?

I'd argue that the customer should be able to change the properties when they want to, they're paying for the flexibility after all right?

In a running WAR

Changing a properties file inside a running WAR file is potentially bad juju as some web containers might see that as a redeploy of the entire WAR file (and we all know that hot deploys of WAR files can cause memory leaks and other unknown issues).

On the CLASSPATH

Setting up your web application to read a properties file from a common location shouldn't be too difficult (especially if you go for the properties file in the same directory as the WAR file approach)

Exploded/working directory

Most web/app servers have an exploded or working area where the current running version of the app is doing its thing. It might be possible to change the property in that version of the properties file. I'm not saying this is the nice way to do things, but you could

How about building a UI?

It sounds like these properties could be business or admin functions. So build em a pretty UI to deal with this, no hand editing of properties files! You might even move away from storing this config in a properties file altogether....

HTH!

|improve this answer
  • Same here. I would build a UI to make it easier for them to change things and to ensure that things are changed in a more controlled manner. That way, you could add things like field validation into the mix which would ensure that the values are somewhat correct before they are added to the properties file. – kelleystar Jul 13 '11 at 15:42
  • I probably should have been more specific, the properties files house information on the host server to run quartz jobs, the JDBC connection string and other environment specific information. – maple_shaft♦ Jul 13 '11 at 16:05
  • 1
    Right, so changing JDBC connection strings and Quartz info on a running instance can get 'interesting'. Are the connection pools cleared out? Does the quartz timing change after all existing jobs are done? All of these can be dangerous to change whilst the app is running. We've had to do a lot of work to make this safe on our running apps... – Martijn Verburg Jul 13 '11 at 17:27
4

Generally, I would tell the customer that if they change the properties file after deployment, they're on their own if anything goes wrong.

If it's a one-time change, maybe you can walk them through it and it will be OK. If it looks like they will want to do this regularly, maybe it's worth adding some kind of admin page or utility to let them change the properties on their own.

|improve this answer
  • 2
    +1: It's their program on their servers, so they can change whatever they want, but they need to actively take responsibility for anything that happens after that. This is especially true if there are potential dire consequences (e.g. aircraft control, bridge control, etc.). You might want to get your legal department involved. – Peter Rowell Jul 13 '11 at 16:18
  • This is a low liability, low risk application. The only somewhat sensitive data stored is a persons name, photo, and an electronic signature. Not sure of the legal implications of that but I imagine they are minimal. – maple_shaft♦ Jul 13 '11 at 17:00
0

If the data in the .properties file needs to change often, I'd say that's data that's a good candidate for putting in a database so that binaries will not have to be modified.

|improve this answer
  • this reads more like a comment (see How to Answer). Consider editing, for example to add an explanation how and why benefits of storing properties in the database can outweigh additional complexity of coding, maintaining and testing it – gnat Sep 19 '14 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.