How to Deploy a WAR File in Production – Tomcat Deployment Guide

Far more detail than you provide is needed to adequately answer this question.

The technologies that you use will be driven by your specific requirements, both functional and non-functional. So in order to know what will best fit your needs, you need to perform requirements engineering. Figure out exactly what the end user wants, and then you'll have a better idea of what tools you can use to get from where you are now to where you need to be. But it's important to focus on both the quality attributes and non-functional requirements as it is the functional requirements.

If you've never done requirements engineering before, I would highly recommend reading the works of Karl Wiegers. He has published two key books - Software Requirements and More About Software Requirements. The first book was required reading in the course I took on software requirements engineering. Wiegers also has a website called Process Impact, which might have some helpful resources and information.

Once you have your requirements, it will be much easier to determine which technology stack can best solve your problems.

However, I do have a few suggestions for you, in the interim:

You have experience with Java, so sticking with the Java environment is probably a safe bet. Don't use a technology to solve every problem that you come across just because you are familiar and feel safe, however. Make sure it can actually solve the problems that you are trying to solve. Otherwise, you are just creating more work for yourself and whoever else has to maintain your software.

Regardless of which solution you choose, the company is going to expect documentation. Depending on the terms of work, you will at least be expected to provide instructions on how to deploy the software and then instructions on how the end user can actually use the system you built. However, there's lots of other things that need to be documented, such as the agreed upon requirements, the design or the final state of implementation when you turn it over, defect reports, time reports, and so on. Make sure you know what you have to deliver, besides working software.

In terms of the database, you have choices between database servers (such as MySQL and PostgresSQL) and embedded databases (such as SQLite and HSQLDB). There are also the NoSQL (such as Hadoop) solutions for data stores. You might want to look into the capabilities of each one and see how you can best meet your requirements. You might need to deploy both, even, depending on the specific requirements. However, you can't choose until you have requirements.

Regardless of the database you use, you'll probably have to be comfortable with things like JDBC and various ORM layers. If you decide to go the web app route, you'll have to be familiar and make choices between Struts, Spring, and a number of other web application frameworks. Be ready to evaluate a number of competing tools, libraries, and frameworks against your requirements. And don't be afraid to throw things away. I believe it was a tip in The Pragmatic Programmer - plan to throw one away. You are going to be making mistakes, and you need to learn from those mistakes throughout this project. It'll help you in the long run.

So, in short, figure out exactly what you have to build before you even try to start thinking about technologies. Given your post, you aren't providing enough information for any reasonable engineer to give any suggestions. And if you don't know or can't specify what you are building to another engineer, there's no way you can build it.

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!