I'm trying to read from a text file in Netbeans. In the top level of my project directory I have foo.txt. Then in my code I have:
File file = new File("foo.txt");
It throws a FileNotFoundException, however. It's a Java web application using Spring and Tomcat, but I'm not sure if those details matter since I'm running the whole thing inside Netbeans. Basically, I just want to know where I need to put the file so Netbeans will read it.
Update - good call guys, it's looking in Tomcat's bin directory. Now this may be a stupid question but, how would I go about getting it to look in my top level project directory? I feel like dropping text files into tomcat's bin would be innapropriate.
You can try printing the absolute path of the File object to see where it is looking on the filesystem.
System.out.println(file.getAbsolutePath());
I would use the following to figure out where to put the file:
System.out.println(System.getProperty("user.dir"));
To directly answer your question, If you're running an application on Tomcat, files will be opened from the current working directory. That will likely be the bin/ folder in your tomcat directory.
You can find out for sure where your program is looking by examining the result of file.getAbsolutePath().
However, for web applications, I would suggest putting files you need to read in your classpath so you don't have to depend on a certain file structure when you deploy your web application.
try System.getProperty("user.dir") to get current working directory
Related
I tried to create an InputStream pointing at an .ico file, which is in a directory in the src directory. I also create an InputStream for a different jar file in my src.
InputStream inIco = Installer.class.getResourceAsStream("/res/" + iconName + ".ico");
InputStream inApp = Installer.class.getResourceAsStream("/res/" + applicationName + ".jar");
that is how I tried to load it. The inputstream for the jar file works, but the other one is null.
Edit: Sorry for the confusion guys. I didn't build the jar, I just ran it from my editor, which obviously gives me different results, now it is working. Thanks for your answers.
getResourceAsStream (gRAS) loads from the same place java loads class files. That's great - it means you can ship your app as a jar and put these resources inside. If it's not working for you, you've misconfigured your build. Specifically, java is first going to determine the classpath root of your Installer.class file and looks there. If you're not sure what that is, run this code:
System.out.println(Installer.class.getResource("Installer.class"));
which will print something like jar:file:/Users/carlos/projects/FooBar/dist/foobar.jar!com/foo/Installer.class
and this tells you that gRAS is going to look in that foobar.jar file.
From there, the resource is loaded relatively to the root (because of that leading slash): Within that jar, it will look for /res/app.ico. Without it, it loads relative to the same dir/package of Installer class (in this example above, gRAS("hello.txt") is the same as gRAS("/com/foo/hello.txt").
To make this work out, your build system is responsible. For maven and gradle, have src/main/java/com/foo/Installer.java along with src/main/resources/res/icon.ico and all should be well. If this is not working out, explain how you've set up your environment because something is misconfigured if this isn't working. If you're using another build tool (such as perhaps ant, sbt, or relying on your IDE to take care of it), name the tool and perhaps we can help address the misconfiguration.
I made a small Java program for academic purposes, its main focus is to read some .txt files and present the information to the user. These files are present in the resources folder, under the src folder.
The program runs as intended when launched from Eclipse.
Using the Launch4j app I was able to successfully create an exe which runs fine and does what's intended, up until I try to read the .txt files I have in the resources folder, which appears not to be able to reach.
I'm guessing that when I launch the exe the run time path would change to where the exe was created, so I created the program in a desktop folder and specified this path in the program, but that doesn't seem to solve the situation.
As an alternative, I moved the .txt files out of the program and once again created the exe in a desktop folder with said .txt files, linked the program to this path and once again it didn't work.
The command used to get the .txt files is:
Files.readAllLines(Paths.get(doc)).get(line)
And doc is simply the path to the intended .txt file.
It's worth noting that I have no previous experience in Java and throughout the development of the program I tried my best to use commands I'd fully understand and to keep it as simple as possible. I hope the solution can be along these lines! I'm very confident this must be a rookie mistake, but I can't seem to find the solution to this specific problem anywhere.
The paths to files in Eclipse are different than the paths to files in an .exe or JAR file.
I will let this other user explain it because I am lazy :p
Rather than trying to address the resource as a File just ask the
ClassLoader to return an InputStream for the resource instead via
getResourceAsStream:
InputStream in = getClass().getResourceAsStream("/file.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(in));
As long as the file.txt resource is available on the classpath then
this approach will work the same way regardless of whether the
file.txt resource is in a classes/ directory or inside a jar.
The URI is not hierarchical occurs because the URI for a resource
within a jar file is going to look something like this:
file:/example.jar!/file.txt. You cannot read the entries within a jar
(a zip file) like it was a plain old File.
This is explained well by the answers to:
How do I read a resource file from a Java jar file?
Java Jar file: use resource errors: URI is not hierarchical
The original post is here, all credit to its author.
Fixing your URL should let you read from that file when you are using the .exe.
EDITED FOR CORRECTION. Thanks #VGR (see comments) for correcting my mistake.
I need some help here. It is redicolous, but my TomCat just does not take the file I want. I am trying to read some properties from a xml file. When I startup tomcat with the WAR file inside it makes a folder "MyApp".
My program points to MyApp\WebContent\myXmlFile.xml
It used to work fine, but i needed to edit the myXmlFile.xml so I did by adding two more properties, but it just doesnt read the new data. How is this even possible? I keep removing the "MyApp" folder from inside tomcat\webapps\ so it makes a new one, but it just keeps getting other data. My code is refreshed, but this file doesn't.
Some help would be appreciated a lot.
I am running Tomcat 7
More detail:
The myXmlFile.xml is inside the WAR file. I am not modifying it in runtime. It is suppose to be some sort of a configuration file. It reads the file once everytime there is a call done to this function. It just reads the xml files and puts properties inside a string.
When i upload the WAR file. I will first use shutdown.bat, than I will use startup.bat when the WAR file is in webapps.
Try restarting Tomcat. In Linux, type
/etc/init.d/tomcat8 restart
Ensure you don't have any other copy of this file with the old values in another folder. I would try to delete (or rename) myXmlFile.xml from the WAR and see what is generated in the Tomcat deploy folder.
I am working on a web app i have java files in it which uses certain files.I want to specify these files using relative path in java so that it doesn't produce mobility issue.But Where should i place a file in a web app so that i can use relative path.? I have tried placing the files under source package, web folder, directly under the web-application.Please help.Thanks in advance
The simplest way to get the current directory of a java application is :
System.out.println(new File(".").getAbsolutePath());
Like that you can consider the given path as the root of your application.
Cheers,
Maxime.
Read the file as a resource. Put it somewhere in the src. For instance
src/resources/myresource.txt
Then you can just do
InputStream is = getClass().getResourceAsStream("/resources/myresource.txt");
Note: if you are using maven, then you are more accustomed to something like this
src/main/resources/myresource.txt
With maven, everything in the main/resources folder gets built to the root, so you would leave out the resources in your path
InputStream is = getClass().getResourceAsStream("/myresource.txt");
For some unusual reason, when I am using FileWriter for Java Netbean, the file gets written into this directory:
C:\Users\myname\AppData\Roaming\NetBeans\7.2\config\GF3\domain1
rather than to my working directory, which is at the desktop.
I used this code to check my User Directory, and it returns this:
System.out.println(System.getProperty("user.dir"));
INFO: C:\Users\myname\AppData\Roaming\NetBeans\7.2\config\GF3\domain1
which is obviously NOT my working directory where my source code is. I thought I could have accidentally configured Netbeans to change the directory, but I checked through NetBeans menu and can't figure out how to undo this.
I have never had this problem before in my previous projects. As simple as the following code, the file should appear in my working directory.
File file = new File("myFile.xml");
Instead now I'm being forced to enter the path name to make the file save into my working directory, which is not going to be dynamic if I change computer.
String dir = "C:\\Users\\myname\\Desktop\\Assignment\\IRAssignmentJ\\";
File file = new File(dir + "myFile.xml");
Please enlighten me how do I solve this.
rather than to my working directory, which is at the desktop
No it isn't. The current working directory is whereever the file got saved, by definition. If Netbeans chooses to change directory to where it was saved, there's nothing you can do about it. If you want it in your home directory, there is a system property for that. If you want it saved somewhere else, use a full pathname.
But the behaviour of the application under Netbeans is of little interest. What matters is when you run it as though standalone, like a customer would.