Could some one help me on this problem. i have webservice , which reads data from configuration files. When i run this webservice from eclipse , i give absolute the path for these webservices of these configuration files , but when i shift the webservice in to server and run, it can not read the config file. so how can i solve this problem. is there a relative path that webservice can understand during run time.
You can put your configuration files in the root of the AAR archive or in the classes folder. Then use getResourceAsStream to read them.
ClassLoader loader = getClass().getClassLoader();
InputStream inputstream = loader.getResourceAsStream(sFilePath);
How are you deploying these configurations. If they're packed inside the .aar file I would expect them to reside in the classpath, and you could access them via Class.getResourceAsStream()
If they're deployed in the .aar file, however, they're going to be difficult to edit post deployment. In that case you may want to deploy them separately as files and put them in a location well-known to the application, and just read them as files.
Related
I am developing a spring boot application which would be used as a non-executable jar by some other user application. The spring boot application(jar) reads the xsd file present in resources folder. When we run it as a standalone application it executes fine.
Code to read the xsd file from resources folder -
File xsdValue = new ClassPathResource("xsd/" + xsdFileName + ".xsd").getFile();
But the problem is, When user application calls the jar then it tries to find the xsd in its own resources folder rather than that of jar's resources folder.
Please advise !!
Any help is much appreciated.
Resources in jar-files can not be gotten as File class, use getResourceAsStream method of ClassLoader class instead.
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 was trying to load a file in a webapp, and I was getting a FileNotFound exception when I used FileInputStream. However, using the same path, I was able to load the file when I did getResourceAsStream().
What is the difference between the two methods, and why does one work while the other doesn't?
The java.io.File and consorts acts on the local disk file system. The root cause of your problem is that relative paths in java.io are dependent on the current working directory. I.e. the directory from which the JVM (in your case: the webserver's one) is started. This may for example be C:\Tomcat\bin or something entirely different, but thus not C:\Tomcat\webapps\contextname or whatever you'd expect it to be. In a normal Eclipse project, that would be C:\Eclipse\workspace\projectname. You can learn about the current working directory the following way:
System.out.println(new File(".").getAbsolutePath());
However, the working directory is in no way programmatically controllable. You should really prefer using absolute paths in the File API instead of relative paths. E.g. C:\full\path\to\file.ext.
You don't want to hardcode or guess the absolute path in Java (web)applications. That's only portability trouble (i.e. it runs in system X, but not in system Y). The normal practice is to place those kind of resources in the classpath, or to add its full path to the classpath (in an IDE like Eclipse that's the src folder and the "build path" respectively). This way you can grab them with help of the ClassLoader by ClassLoader#getResource() or ClassLoader#getResourceAsStream(). It is able to locate files relative to the "root" of the classpath, as you by coincidence figured out. In webapplications (or any other application which uses multiple classloaders) it's recommend to use the ClassLoader as returned by Thread.currentThread().getContextClassLoader() for this so you can look "outside" the webapp context as well.
Another alternative in webapps is the ServletContext#getResource() and its counterpart ServletContext#getResourceAsStream(). It is able to access files located in the public web folder of the webapp project, including the /WEB-INF folder. The ServletContext is available in servlets by the inherited getServletContext() method, you can call it as-is.
See also:
Where to place and how to read configuration resource files in servlet based application?
What does servletcontext.getRealPath("/") mean and when should I use it
Recommended way to save uploaded files in a servlet application
How to save generated file temporarily in servlet based web application
getResourceAsStream is the right way to do it for web apps (as you already learned).
The reason is that reading from the file system cannot work if you package your web app in a WAR. This is the proper way to package a web app. It's portable that way, because you aren't dependent on an absolute file path or the location where your app server is installed.
FileInputStream will load a the file path you pass to the constructor as relative from the working directory of the Java process. Usually in a web container, this is something like the bin folder.
getResourceAsStream() will load a file path relative from your application's classpath.
The FileInputStream class works directly with the underlying file system. If the file in question is not physically present there, it will fail to open it. The getResourceAsStream() method works differently. It tries to locate and load the resource using the ClassLoader of the class it is called on. This enables it to find, for example, resources embedded into jar files.
classname.getResourceAsStream() loads a file via the classloader of classname. If the class came from a jar file, that is where the resource will be loaded from.
FileInputStream is used to read a file from the filesystem.
I am here by separating both the usages by marking them as File Read(java.io) and Resource Read(ClassLoader.getResourceAsStream()).
File Read -
1. Works on local file system.
2. Tries to locate the file requested from current JVM launched directory as root
3. Ideally good when using files for processing in a pre-determined location like,/dev/files or C:\Data.
Resource Read -
1. Works on class path
2. Tries to locate the file/resource in current or parent classloader classpath.
3. Ideally good when trying to load files from packaged files like war or jar.
I was trying to load a file in a webapp, and I was getting a FileNotFound exception when I used FileInputStream. However, using the same path, I was able to load the file when I did getResourceAsStream().
What is the difference between the two methods, and why does one work while the other doesn't?
The java.io.File and consorts acts on the local disk file system. The root cause of your problem is that relative paths in java.io are dependent on the current working directory. I.e. the directory from which the JVM (in your case: the webserver's one) is started. This may for example be C:\Tomcat\bin or something entirely different, but thus not C:\Tomcat\webapps\contextname or whatever you'd expect it to be. In a normal Eclipse project, that would be C:\Eclipse\workspace\projectname. You can learn about the current working directory the following way:
System.out.println(new File(".").getAbsolutePath());
However, the working directory is in no way programmatically controllable. You should really prefer using absolute paths in the File API instead of relative paths. E.g. C:\full\path\to\file.ext.
You don't want to hardcode or guess the absolute path in Java (web)applications. That's only portability trouble (i.e. it runs in system X, but not in system Y). The normal practice is to place those kind of resources in the classpath, or to add its full path to the classpath (in an IDE like Eclipse that's the src folder and the "build path" respectively). This way you can grab them with help of the ClassLoader by ClassLoader#getResource() or ClassLoader#getResourceAsStream(). It is able to locate files relative to the "root" of the classpath, as you by coincidence figured out. In webapplications (or any other application which uses multiple classloaders) it's recommend to use the ClassLoader as returned by Thread.currentThread().getContextClassLoader() for this so you can look "outside" the webapp context as well.
Another alternative in webapps is the ServletContext#getResource() and its counterpart ServletContext#getResourceAsStream(). It is able to access files located in the public web folder of the webapp project, including the /WEB-INF folder. The ServletContext is available in servlets by the inherited getServletContext() method, you can call it as-is.
See also:
Where to place and how to read configuration resource files in servlet based application?
What does servletcontext.getRealPath("/") mean and when should I use it
Recommended way to save uploaded files in a servlet application
How to save generated file temporarily in servlet based web application
getResourceAsStream is the right way to do it for web apps (as you already learned).
The reason is that reading from the file system cannot work if you package your web app in a WAR. This is the proper way to package a web app. It's portable that way, because you aren't dependent on an absolute file path or the location where your app server is installed.
FileInputStream will load a the file path you pass to the constructor as relative from the working directory of the Java process. Usually in a web container, this is something like the bin folder.
getResourceAsStream() will load a file path relative from your application's classpath.
The FileInputStream class works directly with the underlying file system. If the file in question is not physically present there, it will fail to open it. The getResourceAsStream() method works differently. It tries to locate and load the resource using the ClassLoader of the class it is called on. This enables it to find, for example, resources embedded into jar files.
classname.getResourceAsStream() loads a file via the classloader of classname. If the class came from a jar file, that is where the resource will be loaded from.
FileInputStream is used to read a file from the filesystem.
I am here by separating both the usages by marking them as File Read(java.io) and Resource Read(ClassLoader.getResourceAsStream()).
File Read -
1. Works on local file system.
2. Tries to locate the file requested from current JVM launched directory as root
3. Ideally good when using files for processing in a pre-determined location like,/dev/files or C:\Data.
Resource Read -
1. Works on class path
2. Tries to locate the file/resource in current or parent classloader classpath.
3. Ideally good when trying to load files from packaged files like war or jar.
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.