We Keep Coding

External web-application configuration in Tomcat

There's a web application and a number of environments in which it works. In each environment it has different settings like DB connection and SOAP ends-points that in their turn are defined in properties-files and accessed in the following way:
config.load(AppProp.class.getClassLoader().getResourceAsStream(
PROPERTIES_FILE_PATH + PROPERTIES_FILE_NAME));
Thus the WAR-files are different for every environment.
What we need is to build a unified WAR-file that doesn't contain any configuration and works in any environment (for now, Tomcat instance) getting its configuration from outside its WAR-file.
The answer Java Web Application Configuration Patterns, to my mind, gives the full set of common approaches but with just few examples. The most attractive way is configuring JNDI lookup mechanism. As I can guess it allows to separately configure web-applications by their context paths. But couldn't find a simple (step-by-step) instructions in both the Internet and the Tomcat's docs. Unfortunately cannot spend much time on studying this complicated stuff in order to just meet so seemingly simple and natural demand :(
Would appreciate your links at the relevant descriptions or any alternative suggestion on the problem.

If its a case of simply deploying your WAR on different environment (executed by different OS user), then you can put all your config files in the user's home folder and load them as:
config.load(new FileInputStream(System.getProperty("user.home") + PROPERTIES_FILE_NAME));
This gives you the isolation and security and makes your WAR completely portable. Ideally though, you should still provide built-in default configuration if that makes sense in your case.

The approach we've taken is based on our existing deployment method, namely to put the WAR files in the filesystem next to the Tomcat, and deploy a context.xml pointing to the WAR file to Tomcat.
The context descriptor allows for providing init parameters which is easily accessible in a servlet. We've also done some work on making this work with CDI (for Glassfish and TomEE dependency injection).
If you only have a single WAR file deployed to this Tomcat instance, you can also add init parameters to the default global context XML. These will be global and you can then deploy the WAR file directly. This is very useful during development.

Is it possible to deploy multiple war files under the same deployment path?

Let's say I have:
foo.war
bar.war
Is it possible that I deploy them both somehow to the same deployment path? E.g., to access it at:
http://localhost/baz
Are the content of the war files merged somehow? How are file conflicts handled (e.g., let's say both of them has an index.jsp file)?
Thx in advnace!

The servlet specification explicitly forbids this. Deployed web applications may not have identical or overlapping context roots. From the Servlet 3.0 specification, section 10.5:
Since the context path of an application determines the URL namespace of the contents of the Web application, Web containers must reject Web applications defining a context path that could cause potential conflicts in this URL namespace. This may occur, for example, by attempting to deploy a second Web application with the same context path.

Yes & no.
I don't think it's possible to somehow merge them into the same file system path within a servlet container like Tomcat (unless you were to write some kind of complicated, intelligent script to do so). For starters, each .war will have a WEB-INF/web.xml file, and each will rely on the contents of its own file to function -- which would win?
But you conceivably could...
Deploy to 2 different contexts (or containers, or hosts), and employ some kind of load balancer (hardware or software) to route some requests to one, other requests to the other.
Use an "overlay" strategy (such as Maven Overlays) to make a second (and final) .war that is a derivative and extension of another .war file

context.xml vs web.xml in web application

I am developing a small web application application. The objective is to create one welcome index.html page with Ajax + one servlet to handle ajax requests.
Although I thought I would be fine with a web.xml only, I don't want to deploy to /, but to /MyApp. NetBeans's project properties offers options to set a context path, which helps me deploying to /MyApp. However, it automatically adds a /META-INF/context.xml file, which is a bit confusing.
My questions are:
1) Do I really need a context.xml file do deploy to /MyApp instead of /?
2) If answer to 1) is no, how to accomplish the same with web.xml only?
3) What is exactly context.xml to web.xml?

/META-INF/context.xml is a Tomcat-specific config file. It's used to configure how your app is deployed to Tomcat, including, among other things, the context path at which it exists. Other containers have similar files that can be included in a WAR for container configuration. To answer your questions:
No. The embedded context.xml is only one way to set the context path, and as I indicated, it'll only work in Tomcat. In Tomcat, default behavior is to deploy webapps to a context that has the name of the war file, without the ".war" extension.
You can't set a context path in web.xml. That's your application's deployment descriptor. It configures your application, and the context path is external to your app. It belongs to the server/container you're deploying the app to. Configuring a context path is always done in the container's configuration.
If by "config.xml", you meant "context.xml", then I think I've already answered that. If not, clarify your question.

How to use in Tomcat a datasource without having to edit context.xml?

I have to deploy my web app to a shared server where I can't edit the context.xml file to set a new resource factory. Is there a way I could place ALL my hibernate datasource configurations in a file outside my .war, but still inside the deployment folder (the one I have access to).
My ultimate goal is to develop a "portable" web app, so I can easily migrate from one server to another, just editing manually my database configurations in a datasource file. Does anyone knows a functional way to do it?
Ps. I imagine Spring would help with this matter. But I don't feel like to set up it for a simple web app or just for this purpose.

According to http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#context.xml_configuration you can have a per-application context file as well, however that must of course be deployed inside your war file. Your best bet might be to modify your build file so that it uses the correct context.xml when creating the war.

Is it possible to read a properties file from all .war files deployed in a JBoss container

I've managed to deploy a .war to the Jboss web container containing and read the pom.properties located under /META-INF/groupid-dir/artifactid-dir/
To access the file I've used the following code inside a JSP in the same war:
ServletContext servletContext = getServletConfig().getServletContext();
InputStream in = servletContext.getResourceAsStream("META-INF/maven/groupid-dir/artifactid-dir/pom.properties");
This works just fine. But I want to be able to dynamically read pom.propertes from ALL .war deployed in the container. Is this possible or do I only have access to the context for the one war holder my jsp?
-mb

Basically, your application is running on the same machine as the JBoss container, so accessing the files on the local filesystem should be possible, much in the same way you're accessing your own .properties file. I'm not familiar with anything that should prevent you from doing this.
If you want to access files within the war file, you'll need to use the java.util.zip package, as war files are of course normal zip files. Just a friendly reminder.

You will likely have to do something tricky like go through the JBoss MBeans. I realize this is vague, but consider looking into that approach. Here is a link on how to get the MBean server from an application within JBoss (add http://) www.jboss.org/community/wiki/FindMBeanServer (Stackoverflow is preventing me from pasting a link). I would imagine that you could find the Jboss Web mbean, peel off all web application mbeans, then ask each one for its classloader, then proceed to do what you already mentioned.

I don't think that reading a zip or using a jboss mbean are the right way.
I don't think it is tricky and you were on the right track by using ServletContext.getResourceAsStream.
You can probably use ServletContext.getResourcePaths, but several times it seems, to identify subdirectories groupid and artifactid.
Something like
servletContext.getResourceAsStream(servletContext.getResourcePaths(
(String) servletContext.getResourcePaths("/META-INF/maven/")
.iterator().next())
.iterator().next() + "pom.properties")
or
servletContext.getResourceAsStream(servletContext.getResourcePaths(
(String) servletContext.getResourcePaths("/META-INF/maven/")
.iterator().next())
.iterator().next() + "pom.xml")
for pom.xml

If the WAR file is exploded as folder , you should be able to use
String basePath=getServletContext().getRealPath("/");
This approach may not work if WAR file is in archive format

You can only look for resources in your current classpath. The normal operation of a web container is to create a specific classpath for each deployed artifact without access to the other artifacts deployed in the container.
This is very important to avoid artifact A which uses foo-1.0.jar to not accidentially use foo-0.9.jar which is deployed with artifact B.
Hence you will need ask the container for help. This in turn mean you need to write container specific code to do so. This will make you vendor dependent - you may not want that.