We Keep Coding

Tomcat properties configuration file location

I'm new to Java (around 2 months Java experience after coming from a .Net background). I've been asked to support a Java application which uses Spring, J2EE, and an Oracle database.
We have an issue with our deployment process which I'm struggling to understand.
The Java application in question has database connection details in an application.properties file. Its location appears to be configured from a Spring configuration file using the following line:
<context:property-placeholder location="classpath:config/application.properties,classpath:config/bookings.properties" ignore-resource-not-found="true" />
On our Development Tomcat server, the application (called Bookings) looks in this location for the application.properties file:
/usr/share/tomcat/webapps/Bookings/WEB-INF/classes/config
Which is what I would expect, looking at the Spring configuration.
However, on Production Tomcat, the application looks in a different location:
/usr/share/tomcat/lib/config
(In this directory, the file is called bookings.properties.
The original developer has left the company and I have no idea why it would look in a different location for the file (and a different filename).
Any ideas what I can look at, or where this could be configured? It should be noted that both files (application.properties and bookings.properties) are present on both Tomcat servers, so I don't understand the discrepancy?
We have re-deployed the same WAR file to both development and production, and the discrepancy still exists, i.e. the servers still look in different places.

classpath is a directory where you could put some resources (to make it simple, further details on the link).
that's a variable and it's added to the launch command, sometimes it's a bit hidden. But that's the way it works.
May be you can watch in $TOMCAT_DIR\bin\catalina.sh to see how the classpath is defined.
In your case, the folders contained in your classpath are different between development server and production server. That's totally normal.
However, you say that in production the file is named bookings.properties.
But with this line :
<context:property-placeholder location="classpath:config/application.properties,classpath:config/buyer-request.properties" ignore-resource-not-found="true" />
we see that you never try to load a file named booking.properties.
So ask yourself why the file is called booking.properties. And rename it application.properties to see what happen.
Hope this help

Spring Maven: Where to place credential properties

I'm currently developing an application which requires access to an API with credentials. I didn't want to put them hard coded in the application so I created a configuration.properties file for them.
At the moment this file is located in src/main/resources and access it with the following code.
<context:property-placeholder location="classpath:configuration.properties" ignore-unresolvable="true" />
This means that if I change something in the configuration I need to redeploy the WAR.
My question is: Where do I put this configuration file so that I don't need to redeploy in case of a change in the configuration?
I don't want to put it somewhere random on my computer so that I can share my code with other people without to much trouble with the file's location.

I solved it by placing my properties file in Tomcat "D:\Documents\workspace.metadata.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps"
And Access it with the following property-placeholder
<context:property-placeholder location="file:${catalina.base}/conf/configuration.properties" ignore-unresolvable="true" />

I think you're already close.
I agree its a good way to have one .war file and reuse it everywhere without adopting it to a specific environment. That means you cannot include it in the .war
What I would do is creating configuration zip files with the assembly plugin (if there are multiple variations). For example from /src/main/config/env1
Then use an environment variable to point to that folder.
The property placeholder configurer thing in spring then references that location through that system property instead of the classpath:
these zip files can be used to be deployed with the .war file (via ssh using the ant runner plugin or some other way)
That can also be used for the logging configuration. Spring has a resolver that will even reload the log config if you change it on the file system.

cloudbees & ESAPI - how do I point to the ESAPI directory?

I'm using ESAPI for my project, and added the ESAPI configuration directory to src/main/resources so it is copied to my WAR file (I downloaded the WAR from cloudbees, I can see it was put in WEB-INF/classes/esapi/ directory)
Locally, I just point to where the directory is and all works fine, but on cloudbees it just doesn't work for me.
In order to access its properties, ESAPI project tries all kinds of stuff, including checking the org.owasp.esapi.resources system property, so I've added the following code to cloudbees-web.xml:
<sysprop name="org.owasp.esapi.resources" value="WEB-INF/classes/esapi/" />
and I can see that the system property value is found because of the following error in the logs:
Not found in 'org.owasp.esapi.resources' directory or file not readable: /var/genapp/apps/akld3873/WEB-INF/classes/esapi/ESAPI.properties
so it finds the system property (because the path is like I've specified), but when it looks for the actual directory and files in it, I guess the directory is either not there or not readable.
Do I need to move it somewhere else? Inside the WEB-INF directory maybe? Is the setting not right? I've read that others solved similar issues by building a JAR just for this directory, but this doesn't seem like a good solution, there must be a simple setup that will work for cloudbees.

Design for ESAPI lib to require a directory access to configuration is not very flexible.
A general purpose option is to use ServletContext.getRealPath to resolve the absolute filesystem path to this directory and pass it to ESAPI.
Another option is for you to have some init code to copy WEB-INF/classes/esapi content in a temporary directory (using java.io.temp system property to point to the currently configured temp dir for your app) and point ESAPI lib to this path.

Ok so after searching and testing, I finally figured it out.
Cloudbees deploys your web app to the following directory:
staxcat/install/webapp.war/
notice that this is a relative path, with prefix of this path attached it looks something like this:
/var/genapp/apps/xxxxxxxx/staxcat/install/webapp.war/WEB-INF/esapi/ESAPI.properties
so, in order to get ESAPI to work, I had to set the following in cloudbees-web.xml:
<sysprop name="org.owasp.esapi.resources" value="staxcat/install/webapp.war/WEB-INF/esapi" />
this will enable ESAPI to find the directory if in your project it is located under:
src/main/webapp/WEB-INF/esapi
and you should get the following log line:
Found in 'org.owasp.esapi.resources' directory: /var/genapp/apps/xxxxxxxxx/staxcat/install/webapp.war/WEB-INF/esapi/ESAPI.properties

Deploying a WAR file gives me a 404 Status Code on Tomcat?

I am fairly new to Tomcat. I just managed to build a project and exported it as a WAR file. I tried manually copying a WAR file to the Tomcat folder then restarting. It created the folder structure and everything but I get a 404 Status code when I try to reach the application. I tried deploying it through the Tomcat Admin panel but I'm seeing the same behavior. Am I doing anything fundamentally wrong?

Assuming that you have full privileges with the Tomcat installation, try going to http://localhost:8080/manager/html/, if you don't know the password to get into that area, look for the tomcat-users.xml file in your ${tomcat-installation}/conf directory, and that should have it. If it has no entries in it then you will want to add an entry like the following to it:
<user username="username" password="password" roles="admin,manager" />
See whether your application shows up in that screen, and if it does, click on the link and see if that gets you anywhere. If it doesn't, then I suggest following ifishers's advice, and looking at the log files to see if it lists any errors.
But long story short, most likely something is screwed up with your project's web.xml

In more recent times, this condition might occur if JAVA_HOME points to an earlier version of Java than the code in the WAR. Tomcat might use JAVA_HOME to determine JRE_HOME it shows after running startup.bat in Tomcat's BIN directory. While Tomcat may be happy itself with the Java version it gets, for the application this might not be sufficient. In my case, Tomcat 8.0.49 was running alright with JDK1.7, while the application was not initializing at all (yes, it was a Spring Boot application, WAR was being unpacked, but that's all) - without giving any errors. After setting JAVA_HOME to the location of JDK1.8, the problem was solved.

I have the same problem.
My problem is my application name and war file name are different.
I have change war file name to my application name.
Here, when your application is deployed tomcat automatically extract your war file with same name. In my case my service name is my-web-service(i.e.https://localhost:8080/my-web-service/) and my war file name is MY-java-connector-0.0.1-SNAPSHOT.war(this is my project folder name). Now tomcat is looking for my-web=service folder and it finds epicor-java-connector-0.0.1-SNAPSHOT folder. so rename the folder to my-web=service.war and it is working.

I had the same issue, my problem was that I was copying the file via sftp straight into the webapps dir of tomcat which may have caused a polling issue causing it to not deploy correctly.
Tomcat monitors the webapps dir and when it sees the .xml it will crack on and do its thing, problem is that maybe everything hasn't been copied across yet. :(
Best to create a staging folder, move or copy the war to that folder and then use linux mv command to move it into the webapps - mv is atomic so tomcat won't do anything until the operation is complete.
Magic.
Credit goes to a very very random post that I found on javarance which in turn lead to : http://pub.admc.com/howtos/tomcat/ch02.html#stagedir-section
Hope this helps someone else :)

If your'e using Spring-Boot like me to create your WAR file make sure to add the following to your main Application file.
#SpringBootApplication
public class serverTestApplication extends SpringBootServletInitializer {
public static void main(String[] args) {
SpringApplication.run(serverTestApplication.class, args);
}
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
return builder.sources(serverTestApplication.class);
}
}
I was stuck on this for awhile, looked through dozens of guides. This is the video that finally showed me I never configured my application properly:
https://www.youtube.com/watch?v=05EKZ9Xmfws

My best guess is that you have not configured the welcome files in your web.xml. If you go to /app/ you need to have some default file available. Typically, people either created an index.html or they have welcome file settings to point the user to the correct jsp.

I ran into this problem, too.
My simple roundabout solution is to change docBase path.
problem occurs when
docBase=".../tomcat/webapps/app_name.war";
problem solved with
docBase=".../tomcat/webapps/app_foldername/web"

I had the same problem with tomcat and just fixed it by forcing my IDE to create a web.xml file. Mine was missing. It would deploy the project but I would still get the 404 error. I read through several of these tutorials but to no avail. I read somewhere that the web.xml file needed to be configured correctly. Went to find the web.xml in the WEB-INF folder, and there was no folder and no web.xml file. I did a quick google on how to create on using my IDE and then compiled my program with the web.xml output, and it fixed the problem for me. Hope that helps. Cheers!

FWIW I had this problem and fixed it by discovering I was accessing the wrong host, like "http://wronghost:8080/why_is_this_war_not_there" so if it says "XX.war successfully deployed" in catalina.out/localhost.*.out that may be a hint for followers.

I had the same issue. In my case there were no errors in the log files, I had a welcome page defined, it was listed in the Tomcat manager webapp, and it deployed and worked fine on my dev machine. However, visiting the app at http://example.com/myApp just returned a 404 error.
It turns out the problem was in the Apache config. Apache didn't have a mount point, so it didn't know to proxy those requests to Tomcat.
Adding in the appropriate directive fixed the problem:
ProxyPass /myApp ajp://127.0.0.1:8009/myApp

If you have not created any welcome page like index.html JSP or whatever then create one. project must have an index page. I just created one say index.html and the problem is solved..🙏🙏🙏

Did you try
localhost:8080/app
assuming your war file is app.war?
edit for comment -- then your web.xml is screwed up.

Java: Accessing properties file inside a war

I already searched StackOverflow for "properties inside war", but none of the results worked for my case.
I am using Eclipse Galileo and GlassFish v3 to develop a set of web services. I am using a "dynamic web project" with the following structure
Src
-java_code_pkg_1
-java_code_pkg_2
-com.company.config
--configfile.properties WebContent
-META-INF
-WEB-INF
--log4jProperties
--web.xml
--applicationContext.xml
--app-servlet.xml
I want to access the "configfile.properties" inside one of the source files in "java_code_pkg1". I am using the Spring Framework and this file will be instantiated once the application starts on the server.
I have tried the following with no luck
getResourceAsStream("/com.company.config/configfile.properties");
getResourceAsStream("/com/company/config/configfile.properties");
getResourceAsStream("com/company/config/configfile.properties");
getResourceAsStream("/configfile.properties");
getResourceAsStream("configfile.properties");
getResourceBundle(..) didn't work either.
Is it possible to access a file when it's not under the WEB-INF/classes path? if so then how?

Properties props = new Properties();
props.load(this.getClass().getResourceAsStream("/com/company/config/file.properties"));
works when I'm in debug mode. I can see the values in the debugger, but I get a NullPointerException right after executing the "props.load" line and before going into the light below it.
That's a different issue. At least now I know this is the way to access the config file.
Thank you for your help.

If you are in a war, your classpath "current directory" is "WEB-INF/classes". Simply go up two levels.
getResourceAsStream("../../com/company/config/configfile.properties");
It is horrible but it works. At least, it works under tomcat, jboss and geronimo and It works today.
P.S. Your directory structure is not very clear. Perhaps it is:
getResourceAsStream("../../com.company.config/configfile.properties");

Check the location of the properties file in WAR file.
If it is in WEB-INF/classes directory under com/company/config directory
getResourceAsStream("com/company/config/configfile.properties") should work
or getResourceAsStream(" This should work if the config file is not under WEB-INF/classes directoy
Also try using getClass().getClassLoader().getResourceAsStream.

Are you sure the file is being included in your war file? A lot of times, the war build process will filter out non .class files.

What is the path once it is deployed to the server? It's possible to use Scanner to manually read in the resource. From a java file within a package, creating a new File("../applications/") will get you a file pointed at {glassfish install}\domains\{domain name}\applications. Maybe you could alter that file path to direct you to where you need to go?

Since you are using Spring, then use the Resource support in Spring to inject the properties files directly.
see http://static.springsource.org/spring/docs/3.0.x/reference/resources.html
Even if the class that requires the properties file is not Spring managed, you can still get access to the ApplicationContext and use it to load the resource
resource would be something like, classpath:settings.properties, presuming that your properties file got picked up by your build and dropped in the war file.
You can also inject directly, from the docs:
<property name="template" value="classpath:some/resource/path/myTemplate.txt">