I have a setup in which I make use of a txt file (both reading and writing to it) in my program. At present I have it setup such that I use the local filepath on my machine, however I need to package it up into an executable JAR. To do this I've tried switching the filepath string over to the following:
String filepath = MyClass.class.getResource("/resources/textfile.txt");
However, when I run this I get a bunch of errors. After googling the method I found the similar method getResourceAsStream which I have also tried. This seems to return an InputStream object, however I need the filepath as a string ideally. Is this possible? If not what are my options?
Additional Info:
Here are the error messages I receive when trying to read & write to the txt file:
java.io.FileNotFoundException:/Users/Fred/Documents/Eclipse%20Projects/RandomProject/bin/resources/textfile.txt (No such file or directory)
Well the code you've given won't compile, because Class.getResource returns a URL, not a String. You can't treat the resource as "just another file" - because it's not.
You should basically change whatever needs to read the file to accept an InputStream instead of a filename, and then pass in the result of calling getResourceAsStream().
The method returns URL, not String. It's signature is public URL getResource(String name)
You might want to do:
String filepath = MyClass.class.getResource("/resources/textfile.txt").getPath();
I have a setup in which I make use of a txt file (both reading and writing to it) in my program.
For read only, the resource can be in a Jar on the application class-path. It is very rare (in production) for resources on the application class-path to be writable. This text file will most probably need to be put in a reproducible path (e.g. a sub-directory of user.home - where the sub-dir is based on the package name) and used as a File from that path.
Or to put that a different way. I think you are pursuing the wrong path, to achieve the goal.
If you expect to directly write to a text file inside a JAR, my friend then you are wrong all the way! Please post some more code for us to understand what is it exactly you want to achieve and how you think it could be done.
Related
I am using NetBeans 8.0.2 (I know there already is v8.2 but it has a lot of bugs for me so I got back to v8.0.2) and I need a string path to my .obj file for a parameter attribute like this:
api.parameter("filename", "obj/someFile.obj");
Above example worked in a previous version of my app where I had that .obj file placed in a folder called "obj" in the same directory as my .jar file, but now as I am trying to rather include it in the JAR itself with code:
api.parameter("filename", MyClass.class.getResourceAsStream("/someFile.obj").toString());
...it is not working anymore as the path string interpretation is not a path to a file, it looks more like this:
java.io.BufferedInputStream#215d7ea7
...where, of course, my code is expecting something like normal path string, I would said something in this pseudo-code manner:
api.parameter("filename", "<this.jar>/someFile.obj");
So after a fiddling a bit around StackOverflow I've found pieces of code that I thought could actually enable me to directly place that path as a string:
URL jar = MyClass.class.getProtectionDomain().getCodeSource().getLocation();
api.parameter("filename", jar + "/someFile.obj");
But surprisingly although I checked several times if the file actually really exist in my built jar file (and yes, it is there in the root) it still gives me this error:
java.io.FileNotFoundException: file:\Z:\_JAVA_\MyProject_0_018\dist\bin\myjar.jar\someFile.obj <The filename, directory name, or volume label syntax is incorrect>
And I am 100% sure the name of the file is correct, also its placement in the root of my jar file.
Or does it actually thinks that myjar.jar is a directory?
I am desperately trying to find a solution to this "path string" mess.
Your protection domain's code source location likely returns not what you'd expect it to.
You should use getResource(name) directly, like this:
URL locator = MyClass.class.getResource("someFile.obj");
api.parameter("filename", locator.toString());
I am using this code
String path = getClass().getResource("Template.xls").getPath();
When I run it on my machine (windows), everything is good. I even did system.out.println on the get resource part and on the get path part and the results were:
file:/C:/Eclipse/Netbeans/SoftwareCom/build/classes/assets/Template.xls
/C:/Eclipse/Netbeans/SoftwareCom/build/classes/assets/Template.xls
However I am getting the following error reports from some users
java.nio.file.InvalidPathException: Illegal char <:> at index 4:
file:\C:\Software%20Com\SoftwareCom.exe!\assets\Template.xls
Iam not sure whats happening or why would it work for some and not others
Any pointers?
To answer this question properly, it would be helpful to know what you want to do with the path information. To read the file, you don't need the path.
You could just call
getClass().getResourceAsStream("Template.xls")
If you really want to know the path, you should call
URL url = getClass().getResource("Template.xls");
Path dest = Paths.get(url.toURI());
This might cause problems as you seem to pack your java files in a windows executable. See Error in URL.getFile()
Edit for your comment:
As I wrote above, you don't need the path of the source to copy. You can use
getClass().getResourceAsStream("Template.xls")
to get the content of the file and write the content to whereever you want to write it. The reason for failing is that the file in your second example is contained within an executable file:
file:\C:\Software%20Com\SoftwareCom.exe
as can be seen from the path:
file:\C:\Software%20Com\SoftwareCom.exe!\assets\Template.xls
The exclamation mark indicates that the resource is within that file.
It works within Netbeans because there the resource is not packed in a jar, but rather is a separate file on the filesystem.
You should try to run the exe-version on your machine. It will most likely fail as well. If you want more information or help, please provide the complete code.
I faced this same issue and go around it by using the good ol' File API
URL url = MyClass.class.getClassLoader().getResource("myScript.sh");
Path scriptPath = new File(url.getPath()).toPath();
And it worked!
I have a library which is used by a program. This library loads a special directory in the resources folder.
in the library I have the method
public class DataRegistry{
public static File getSpecialDirectory(){
String resourceName = Thread.currentThread().getContextClassLoader().getResource("data").getFile().replace("%20", " ");
File file = new File(resourceName);
return file;
}
}
in my program I have the main method
public static void main(String args[]){
System.out.println(Data.getSpecialDirectory());
}
When I execute the getSpecialDirectory() in a junit test within the data program, the resource is fetched and all is well.
When I execute the getSpecialDirectory() in the main method outside the data program (imported jar) I get the jars data directory and not the directory the program executing the thread is expecting.
I figured getting the parent class loader would have solved this issue... I believe I may have a fundamental issue in my understanding here.
For clarity:
(library)
Line 15 of this file: https://gist.github.com/AnthonyClink/11275442
(Usage)
Line 31 of this file:
https://gist.github.com/AnthonyClink/11275661
My poms may have something to do with it, so sharing them is probably important:\
(Library)
https://github.com/Clinkworks/Neptical/blob/master/pom.xml
(Usage)
https://github.com/Clinkworks/Neptical-Maven-Plugin/blob/master/pom.xml
Maven uses the target/classes and target/test-classes directories to compose the classpath used to run unit tests. The content of your src/main/resources and src/test/resources gets copied to these locations together with the compiled java sources (the .class files).
java.lang.ClassLoader.getResource returns a java.net.URL.
In the unit test situation, ClassLoader.getResource returns a file:// schemed URL, and your code works as expected.
When your code is executed when packaged in a jar file, ClassLoader.getResource no longer returns a file:// schemed URL. It can't because the resource is no longer a separate entity in a file system - it's buried inside the jar file. What you actually get is a jar:file:// schemed URL.
jar: URLs cannot be accessed through a [java.io.File] object.
If you only need to read the content of the resource you should use java.lang.ClassLoader.getResourceAsStream(...) and read the content from that.
Note that it is not possible to update the content of class loader resources.
Do you want the directory where the Java program was loaded from ? Can try
File f = new File(".").getCanconicalFile();
Or if you want all the places could try parsing the classpath from System.env or use the default class loader
If you want a directory relative to the jar from where your classes were loaded: Quoting from http://www.nakov.com/blog/2008/06/11/finding-the-directory-where-your-java-class-file-is-loaded-from/
URL classesRootDir = getClass().getProtectionDomain().getCodeSource().getLocation();
The above returns the base directory used when loading your .class
files. It does not contain the package. It contains the classpath
directory only. For example, in a console application the above
returns someting like this:
file:/C:/Documents%20and%20Settings/Administrator/workspace/TestPrj/bin/
In a Web application it returns someting like this:
file:/C:/Tomcat/webapps/MyApp/WEB-INF/classes/
FYI This might apply if the user id running program cannot read all folders: http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getProtectionDomain%28%29
or pass a .class object of the calling class as a parameter and get its classloader
There is no guarantee that you have a directory for your resources as far as I know. Java provide methods to get a resource as a InputStream, but nothing that can easily get the File for a resource, although it is possible to get the URL for a given resource.
If you need a special working directory in your application, I recommend having that passed as a system property, a program parameter, a web application parameter, or something else that lets you know where your application files are. You can even populate this directory with a ZIP file that you include as a resource in your application, as the ZIP libraries in Java do accept input streams as parameters.
While user #tgkprog is right and his answer correct, I can hardly imagine that you really want what you seem to have asked for and what he correctly answered in (3). Please edit your question and explain
what the output should look like if resourceName would be printed to the console,
if you really want the JAR file's location (in my test case that would be something like file:/C:/Users/Alexander/.m2/repository/com/clinkworks/neptical/0.0.1-SNAPSHOT/data, which does not make sense because you do not want to read from or even write to the local Maven cache),
or if you maybe rather want to read a resource directly from the JAR file or any other location such as the current working directory etc.
Otherwise I am afraid there is no good way to answer the question.
When I call the jrxml file through .load(), its throw a exception FileNotfoundException.
I have tried with absolute path, but it does not work. Please help.
FileNotFoundException generally means the file is not there. Get the path from your code and paste it in you filesystem explorer and see if it exists.
If it does, it means it is for some reason inaccessible:
This exception will be thrown by the FileInputStream, FileOutputStream, and RandomAccessFile constructors when a file with the specified pathname does not exist. It will also be thrown by these constructors if the file does exist but for some reason is inaccessible, for example when an attempt is made to open a read-only file for writing.
You should always use absolute paths in Java IO stuff. Apparently the one you tried was plain wrong. Maybe you just guessed it based on the deploy location of the webapp. You shouldn't do that. If the jrxml file is actually located in the webcontent, then you can use ServletContext#getRealPath() to convert a relative web path to an absolute disk file system path which you in turn can use further in the usual Java IO stuff.
Assuming that file.jrxml is located in webcontent root (e.g. accessible by http://example.com/contextname/file.jrxml), here's an example:
String absolutePath = getServletContext().getRealPath("file.jrxml");
File file = new File(absolutePath);
It depends on how you give it the reference to the file. Looking at the documentation for the JRXmlLoader http://jasperreports.sourceforge.net/api/net/sf/jasperreports/engine/xml/JRXmlLoader.html
you can see that you can pass it in a reference to a File object. You are probably just passing in a string and that might be wrong.
Try something like
String path = "/tmp/test.jrmxl";
File jrxmlFile = new File(path);
JasperDesign jasperDesign = JRXmlLoader.load(jrxmlFile);
with the appropriate try/catch and more and then debug on the file first before you worry about the loader.
You should probably get some of the jasperreports documentation. The books are quite good for that basic stuff.
I have a jar file with bundled resources (language model binary files) that need loading at run time. The directory structure within the jar is
tagger/app.class
tagger/models/stop/SentDetect.bin.gz
where SentDetect.bin.gz is a binary whos path is loaded into a thirdparty class (SentDetector) as a String parameter, i.e.
URL url = this.getClass().getResource("models/stop/SentDetect.bin.gz");
SentenceDetector sdetector = new SentenceDetector(url.getPath());
While it runs ok in Netbeans, when I try to run it as a jar from command line, I get a FileNotFound Exception at the constructor. I have double checked that the binary is included in the compiled Jar file.
I believe the solution would usually be to load the data in as an input stream using getResourceAsStream(), but this is not an option here, as the url is being passed as a String parameter to a third party constructor, which leads me to believe the problem is with how the url is being parsed to a String?
I have tried:
url.getPath();
url.getFile();
url.toURI().getPath();
url.toString();
and all are giving different paths to the file.
It sounds like that should be fine, if the binary is definitely in the right place and the jar file is definitely in the class path. (I assume it can find the class itself? I'd expect so, given that you're using this.getClass()).
One thing which might be causing issues is filename casing - when it's loading the file from the file system, if you're using Windows that'll be case insensitive; in a jar file it'll be case sensitive. Check the case in code matches the case in the jar file.
You can't access a resource in a Jar file via java.io.File. You should provide an alternate constructor for SentenceDetector which either accepts an InputStream rather than a String, or which accepts an URL and uses URL.openStream() to get an InputStream.