We Keep Coding

user.dir is incorrect while using tomcat web app in eclipse

I have a configuration project that few projects are using it.
All of my project under the same workingspace.
workingspace/configuration
workingspace/webapp1
workingspace/mongoDB
workingspace/model
mongoDB and the model project are using the configuration jar project and able to read the xml files using relative path ../configuration/conf/....xml
when using the
System.out.println("Working Directory = " +
System.getProperty("user.dir"));
inside both of them, I'm getting the correct path (workspace)
while trying to do it from the web app servlet i'm getting the folder of eclipse.exe that causing some problems.
How can i fix the user.dir defalte path for the web app?

At runtime, e.g. when you're not running from inside eclipse, you probably want to work in a defined directory as well - I'd suggest to explicitly configure a specific directory. When you're running within an appserver, you might run as an unpriviledged user that doesn't have a home directory writeable at all (when the account is properly administered with minimal permissions). This differs from applications that are launched ad hoc. In fact, you probably can't assume that your application server runs as the same user as your standalone apps do.
Another alternative is to utilize the system's temp directory - if these are truly temporary files. This could be assumed writeable, or complaints if it isn't do make sense.

Java webapp - where to put application-generated files?

I'm working on a Java web application that needs to store uploaded files in one directory, and an embedded Neo4j database in another directory. I'm deploying the warfile to Tomcat to serve the application, and the application needs to be runnable under Tomcat in either Linux or Windows.
Where exactly should I be putting these two directories on the host system's filesystem?
I'm confused since I'm accustomed to storing information in databases specified via a URL, etc. Thanks for the help.

Is there a chance webapp have two or more instances running at the same time, say in a same Tomcat with two /path names?
Java has system property user.home you could always create a subfolder on it. Current user is the one running Tomcat server. Print properties to sysout for debug purpose.
Reading a webapp name at runtime you can use servletContext.getRealPath("/") function. You get a filename path to $tomcat/webapps/mywebapp and use last folder entry. Define ServletContextListener in web.xml so you can read webapp name at startup.
Use naming convention ${user.home}/tomcat/${webappname}/ and store any file you please.
Or define a webapp context-param variable in web.xml file and let deployer create an appropriate folder.
http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getInitParameter%28java.lang.String%29

Locating created file with Java EE and Tomcat

I have created a dynamic web project, and use Apache Tomcat as a server.
In my servlet I'm creating a text file and want to reuse that in a JSP. However they are by default created in the installation folder of Eclipse when I do something as simple as the following:
File f = new file("test.txt").
I don't know why this happens. Is there a way to create the file in the WebContent directory as I want to make that file available for download in my JSP.

Java has a concept of the "current directory". When you start an application via Eclipse, this may indeed point to your installation directory. If you don't specify any path, a file will be created in this current directory. Hence the reason why your test.txt ends up there.
The WebContent directory is a something that is specific to Eclipse. Your code should not depend on putting anything there. You only start your application via Eclipse when you're developing it, not when you're deploying it to a live server.
The content of this directory will become the root of your .war, which is a well known location independent of how you start & deploy you app, BUT you still cannot depend on writing anything to this location at run-time. You might deploy your application as a packaged .war (likely for live deployments) or you may deploy your application unpackaged but then your application server may simply not pick up any changes done at run-time.
What you can do if you are sure your application only runs on a single server is writing the files to a well known location on your file system, such as /tmp, or /var/yourapp/files, etc. The code serving up those files can then pick them up from that location.
If you want to play it 100% safe according to the Java EE rules, you'd store your files on something like an FTP server that has a configurable address. Technically your war could be shipped between nodes on a cluster and requests could end up going to different machines, so depending on a local filesystem wouldn't work then.

Executing this statement this.getServletContext().getRealPath (""), you'll obtain the path where Tomcat WebServer is pointing at at runtime. You could add a folder "MyFolder" and call this statement:
new File(this.getServletContext().getRealPath ("") + "/MyFolder/test.txt");
Anyway, the default path looks something like:
...\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\<NameOfYourProject>
Note that when you create a new file, it won't appear in your immediate workspace (check the .metadata path), unless you change the runtime location tomcat should point at.

Preventing access to war file without using .htaccess / apache conf

Currently when I deploy a war file to Tomcat it can be downloaded from the URL via something like foo.com/myapp.war.
Most places recommend that you put an entry in a .htaccess file to prevent public access to any war files, or failing that an equivalent entry in your Apache config.
Unfortunately, my host does not provide access to the Apache config (although I can access Tomcat confs) and .htaccess files do not work for all Tomcat/Java related hosting environments. Pretty disappointing. They have been rather unhelpful in this respect.
Without resorting to something like "finding another host" (other than this issue they are fine - I'd rather stay here until my app grows too big), is there anything else I can do to prevent public users accessing my war files, yet still allow Tomcat to deploy the apps when it scans them?
For example, is it possible to specify one directory for Tomcat to scan for war files yet have it deploy the war into the public directories?
Thanks.

It is probably better to ask at https://serverfault.com/. It all boils down to how Tomcat is setup.
The vanilla setup will have a folder called webapps under CATALINE_HOME. You put your WAR archives there (they get auto-extracted and deployed). These folders will not be accessible from HTTP (you cannot download WAR archives from some URL like /webapps/my-test.war). These apps in webapps folder are deployed to some context roots. For example an application my-test.war will by default get deployed as yourhost.com/my-test/.
If you can download your WAR archives from foo.com/myapp.war maybe you can check out what does the CATALINA_HOME/webapp/ROOT app is doing. By default this is deployed under the foo.com. Ask from the host the Tomcat configuration files to figure what kind of custom configurations are they using.

You can place your .war files in any location Tomcat has access to. But you will have to tell Tomcat about it, so it picks them up. You can do this by placing a configuration XML file in
<CATALINA_HOME>/conf/Catalina/localhost/myWebapp.xml
There are samples on what to put into that file myWebapp.xml, e. g. here, step "4)". And of course, the official documentation.

How to differentiate between test and production properties in an application?

We're developing a big J2ee e-sales solution. It's got a lot of integrations: CMS, ERP, Mail server etc. All these systems are divided into test and production environments.
We need to deploy our application to our test servers with test configuration and when deployed to our production servers it should use the production configuration. How do we make our application select the correct properties?
The thing we've tried so far is this:
All our property files contain test properties and production properties
test.mvxapi.server = SERV100TS
test.mvxapi.username = user
test.mvxapi.password = password
test.mvxapi.port = 6006
test.mvxapi.cono = 600
mvxapi.server = SERV10001
mvxapi.username = user
mvxapi.password = password
mvxapi.port = 6001
mvxapi.cono = 100
The Util that reads these properties has a switch: isTest() which prefixes the key with "test."
public String getProperty(String property)
{
return properties.getProperty(prefix + "" + property);
}
The switch is set by another property which is created by our build server. When the .EAR is built the script for our production servers injects (input to build.xml) "isProduction=true" into system.properties.
<propertyfile file="${buildDir}/system.properties">
<entry key="isProduction" value="${systemType}"/>
</propertyfile>
I'm not sure this is the best way to do it. If for some reason "isProduction=false" is committed wrongly to our production environment all hell is loose.
I've read people have properties locally on the server. But we really don't want to have files spread around. We have cluster of production servers. Making sure every server has the right property file doesn't seem fail-safe

What you want to avoid is having the config file inside the EAR, the problem with this is that you need different EAR's for different environments, and also, changing the config file requires a rebuild.
Rather deploy the same EAR to every server but configure each server with a different URL resource. iow, add a JNDI URL resource to all the servers you deploy to that point to the config file for that resource. If you have read only SVN access to your repo then create the config files on the svn repo, or any repo you can access via a URL. The cool thing here is that all your configuration is centralized and thus managing them is easy.
What I've done (by customizing with spring) is make sure that JNDI URL resource optional. So, if it's there, the app will use it, if not, it won't. The app starts up whether it's there or not. That way, even when running with no JNDI resource available, the app still works (development environment for example).

You deploy an EAR? Then put the properties needed in JNDI.

I can't say if this is the best way, however, what we do is include a client and server jar which houses the properties accordingly. We then include those jars in the EAR file. So during our build process we include the appropriate (QA, TEST, PROD) jars for the environment in which we are deploying to.
The downside is we have to manage three sets of environment jars and the build team has to be careful not to deploy the incorrect one. In fact, it has happened once that we had a PROD jar deployed to our QA environment and QA data was getting put into production....yes that sucked and was a major mess to clean up.
I will be watching this discussion because I often wonder how we can make this process better/safer. Great Post +1

In a previous J2EE project, we've been doing exactly that. The build process (an ant script) put together the right config files, added them to a certain jar which was then put into the EAR file for production environments, test, training, QA, etc.
The file name of the EAR file contained the name of the target environment, so it was basically impossible to deploy a file to the wrong environment. If we built for target 156p2 (factory 156, production env. 2), this would be part of the file name of the EAR file and ant would include config_156p2.xml. If the target was incorrect, the EAR file's name would be wrong and as a last failsafe the guy who deployed it would notice.
The build file had to contain this: one ant target to start the build for each environment which would set a property that told ant which config file to include.
The only difference between the EAR files would then be the config files. Everything else was identical. There is a possibility, of course, that someone might have written a wrong value to a config file for a certain environment. However, in practice this never happened in several years, even with some pretty junior developers and about fifteen target environments (different test, QA, training and production servers in different countries).

We have 3 folders for this purpose in our projects, each one contains configuration files (filenames are the same between the folders):
personal: contains paths to test db, server, etc
test: contains paths to the servers shared with my colleagues
production: contains... well you guessed
When I build my project I add the suited profile to Intellij Idea project build, in the desidered module, this basically means that i am adding a different folder to the project structure, but because filenames are the same what changes are only profile properties.

Very old post still responding in case someone checks it. In each application server you can set System properties e.g
Wildfly Management Console --> Configuration --> System Properties
There I add a variable SERVER_ENVIRONMENT with value as DEV/UAT/PROD.
In my java code I use:
System.getProperty ("SERVER_ENVIRONMENT")
which gives me value from the server.

Like #Alberto-Zaccagni said you can have separate folders with properties files that exist only in respective environment. Your code checks for existence of folder starting with PROD then UAT then DEV and when it finds a path exists it uses the properties files there.