I've developed a web application that worked fine in JBoss 4. Now, I need to make it work in Tomcat 6, but I'm having trouble to access some properties file. I use the following code to read read these files:
InputStream is = Thread.currentThread().getContextClassLoader()
.getResourceAsStream(fileName);
if (is == null) {
throw new StartupError("Error loading " + fileName);
}
properties.load(is);
As I've said before, it works fine in JBoss 4. But when I deploy my app in tomcat, it doesn't find the file, assigning null to 'is' variable, causing the StartupError to be thrown. The file is located at WEB-INF/config directory, and the webapp is deployed as a war.
Any solution for this problem?
Thanks,
Alexandre
Put the properties files in WEB-INF/classes.
Or include them in the root of one of your webapp Jar files, although this makes it harder to edit them. This is good if you're selecting properties within a build script and don't want to edit them once deployed.
I assume that Tomcat does not add WEB-INF/config into your webapp classpath.
from http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
WebappX - A class loader is created for each web application that is deployed in a single Tomcat 6 instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application archive, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application archive, are made visible to the containing web application, but to no others.
Related
I deployed a war file onto a Tomcat 7 instance running on a remote Linux machine and I'm getting FileNotFoundExceptions.
One of the referenced jars in the project, which contains code that I did not write, uses several files (which I have included, but it is not finding). These files are located in the classes folder. It appears the classpath I have set for the project is being ignored by this jar. These files that it uses, e.g. .properties files are external to the jar.
Here is an example of how it is invoking the files:
FileOutputStream fos = new FileOutputStream("Key.ser");
I was getting these errors when developing the source project in Eclipse. I was able to configure the project to tell it where to find these files via Run Configurations -> Arguments -> Other but the exported .war file appears to not have this bundled with it, only the source project has it. Now I'm seeing them again when trying to deploy the application to Tomcat on another server via war file.
How do I configure the deployed jar file in the deployed Tomcat 7 webapp to find these files that the jar uses? I am loathe to change the code since I did not write it so am really hoping to avoid this.
I am able to get this to work on a local Tomcat 7 running on Windows instance integrated with Eclipse as explained earlier so I'm wondering if maybe this can be duplicated?
You will not be able to find the file by simply referencing the file name using FileOutputStream. You are correct to place the file in the 'WEB-INF/classes' directory, which will allow it to be located on the classpath.
To load the file, you need to load it as a classpath resource using something similar to this:
String classpathLocation = ""Key.ser"";
URL classpathResource = Thread.currentThread().getContextClassLoader().getResource(classpathLocation);
// Or if you want it as an inputstream:
InputStream input = Thread.currentThread().getContextClassLoader().getResourceAsStream(classpathLocation);
I've installed Eclipse with web development and during download have installed Tomcat7 to dir E:\Eclipse\tomcat7.
When in Eclipse and trying to test the program I'm getting a realPath of
C:/Users/user/Documents/eclipseJEEWorkspace/javaWebPages/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/org.example.web/WEB-INF/classes/
as my real path and not what I expect which is E:\Eclipse\tomcat7\webapps\org.example.web/WEB-INF/classes/
1) how do I get the real path of the servlet rather than the temporary path...
or am I missing something with how Eclipse uses the installed server? If this is the way then do I have to continuously create the WAR and fiddle around recreating/deleting all the time?
The reason for this is I'm also trying to get a JAVA Servlet getting access to a file in a path higher than webapps. I'm new to servlets....
My development includes third party software that all reference an individual file our.properties so changing the structure is unfortunately not a option.
My directory structure is:
/tomcat
/mycompany
/properties
our.properties //the file we want to access
/*otherfiles
/html
/*not used in this context but to show usage
/javascript
/*not used in this context but to show usage
/webapps
/org.example01.web
/META-INF
/WEB-INF
/org.example02.web
/META-INF
/WEB-INF
/org.example03.web
/META-INF
/WEB-INF
How do I tell my Servlet to access the our.properties file?
I've tried getPath, getResource but without getting the first bit to work, I doubt I'll be getting anywhere fast.
Thanks
When you run Tomcat under Eclipse, via the Tomcat plugin, the webapps path is changed. Eclipse uses .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/ folder to deploy the project. That's not a temporary path, it's the actual path since your web application is deployed there.
If you run tomcat from command line, or as a service and deploy your web application, you'll see that the path of the servlet will be as you expected.
In order the change the default path to deploy for Eclipse, double click to your Tomcat under Servers view and modify Server locations section.
I previously used the following to get my context path on Tomcat-5.0.28 and earlier:
String context_path = context.getRealPath("/WEB-INF/");
This worked to return the path to that folder.
But on OpenShift (Tomcat 6 - JBoss EWS 1.0) this returns
/var/lib/openshift/53.*context_id_here*..18/jbossews/null
The null should be:
work/Catalina/localhost/_/WEB-INF
How can I get the path to the WEB-INF folder on OpenShift using JBOSS/Tomcat?
A little background information: When I ran this struts webapp on my own Tomcat server, I deployed a appname.war file in the webapps directory and waited for it to expand (since I had set that option in the server.xml file). Then I move a folder to webapps/appname/ folder with xml files I need to read and write to for my app to work. On OpenShift I used jar xvf appname.war to extract the war file by hand (because that's the default and I don't know how to change it), and then moved the files folder (from the same directory as the war file in my folder after a git add and push) to work/Catalina/localhost/_/WEB-INF/
This is causing a NullPointerException for me when trying to use that path as shown above.
I think you should be using something like getServletContext or getRealPath, and reading it from the web root instead of trying to find the file on the physical disk. That way your war file can run anywhere without issue. Try looking up both of those and see if one fits your use case.
I'm trying to deploy a war on Tomcat 7.0, and in the server.xml file, I've set unpackWARs = true and autoDeploy = true.
Since I want this war file to be the default web application, I have deleted the ROOT folder inside ...Tomcat7.0/webapps. Then on, when I try to start the Tomcat service, I see a behavior that I have yet failed to identify a pattern in:
Sometimes, the war is unpacked to a newly created folder named
'ROOT'.
Some other times, it is unpacked to a folder that is named
the same as the name of the war file. E.g. if the war file is
'MyWebApp.war', it's unpacked to a folder named 'MyWebApp'.
It seems to be completely erratic and random, but I am sure there is method behind this apparent madness. As a rule, I am not sure if there is anything that dictates the creation of a ROOT folder. I have tried to edit the server.xml file and add context to my web application in it, but it doesn't seem to make a difference.
What am I missing? Thanks in advance!
Name your war file ROOT.war. It will unpack to ../webapps/ROOT and map to / context
Tomcat documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html)
Only if a context file does not exist for the application in the
$CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at
/META-INF/context.xml inside the application files. If the web
application is packaged as a WAR then /META-INF/context.xml will be
copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
match the application's context path. Once this file exists, it will
not be replaced if a new WAR with a newer /META-INF/context.xml is
placed in the host's appBase.
Text in bold is clear. But I notify as not true. (I need exactly this behaviour)
Here are steps:
aaa.war with context.xml included into META-INF
copy to webapps. tomcat deploys. File conf\Catalina\localhost\aaa.xml OK
change aaa.war by changing META-INF/context.xml
copy to webapps
File conf\Catalina\localhost\aaa.xml is changed!!!
What is wrong? Is it a bug or a hidden feature?
Background - the issue I want to resolve:
Configuration independent build and installation. I plant to ship war file. Client per-configures his Tomcat using his own settings. when I ship a new release I just delivery the war without config and when deployed it will use client specific configuration.
By documentation the best place is the context.xml But if it overwritten each time it make no sense to use at all. (why would I use JNDI and such a things if new deliverable has to created? Changing something in build-time is not a big configuration advantage.)
Environment: windows, tomcat 6.0.33
I've run into the same problem and the documentation is at least inadequate, if not directly misleading.
The problem is, that if you copy a new version of an already deployed WAR file to the webapps directory, Tomcat will not redeploy the existing application but undeploy the old application and then deploy the new application. The difference may first seem insignificant, but the problem is that during undeployment of the old application, any context files in conf/Catalina/localhost are deleted as well. Then, the new context file from the current WAR file will be copied to conf/Catalina/localhost during deployment of the new application.
The only feasible solution I've found is not to deploy the new application as a WAR file, but to replace or overwrite the expanded directory, e.g. not to copy aaa.war to webapps/ but to unpack aaa.war directly into webapps/aaa/.