Develop Reference

Read a file from same folder as JAR file but still read resources folder when loading from IDE

I've been trying to make jar application that can read a csv file in the same directory as it. This is, however, proving difficult as my means for accessing the file currently is:
InputStream is = getClass().getClassLoader().getResourceAsStream(filename);
Which works for my program running in the IDE and for my tests but doesn't work when I run the program from the compiled jar file. I have no idea how to get it to work for both. I seriously can't understand this path stuff, it seems like there are a million ways to do it and only one of them work for only one specific scenario.

I've been trying to make jar application that can read a csv file in the same directory as it.
Ah, there's your problem. That just isn't a thing.
There are only 2 types of files:
Application Resources
These are read only, and are as much part of your app as your class files are. It is not in any way relevant to think about 'editing' them - that's not the kind of thing they are. It is reasonable to assume that if this resource is somehow missing, the app is as corrupt / misinstalled as it would be if class files are missing.
For this, you use .getResource and .getResourceAsStream. And note that getClass().getClassLoader() is wrong, you want MyClass.class.getResource and then add a slash if you want to go from root (because getClass() potentially breaks when you subclass, and going via classloader is [A] just typing for no reason, and [B] breaks in bootload scenarios. MyOwnClassName.class.getResource never breaks, so, always use that).
This asks java to look in the same place class files are and nowhere else. Your class files are inside the jar files, and not next to them, therefore, it won't find a text file that is sitting next to jar files.
it does not make sense that it does work during development: That means you shoved a file inside the resources folder, which is equivalent to having a CSV file inside the jar file. You must have gone out of your way to tell your build system to do weird things. Don't do that.
If that CSV file is not intended to be user editable it should be inside the jar file and not next to it: That makes it an application resource. Examples of application resources:
You have a GUI, and you need to store the icon files and splash screen art and such someplace.
You ship static data with your app, such as a table of all US states along with the zipcodes they use (could be a text or csv file for example).
Templates of config files. Not config files themselves.
DLLs and the like that you need to unpack (because windows/linux/mac isn't going to look inside jars for them).
You're a webapp and you want to ship the HTML static files along with your webapp.
If this is what your CSV file is, the fix is to put it in the jar, not next to it, then load it with MyClass.class.getResource(name).
Config files and project files
For example:
For a rich text editor (like, say, LibreOffice Writer), the .odt files representing your writings.
Save games for a game.
A config file, which can be edited by the user, or is edited by your own app in a 'preferences' dialog. This stores for example whether to open the app full screen or not, or authentication info for a third party API you're using.
These should not be in the jar, should not be loaded with .getResource at all, and should not be in src/main/resources in the first place.
They also should not be next to your jar! That's an outdated and insecure model (the idea that editable files sit in the same place the app itself sits): A proper OS configuration means that an app cannot write to itself which is most easily accomplished by having it be incapable of writing to its directory. Some OSes (notably, windows) did this wrong for a while.
For example on windows, your app lives in C:\Program Files\MakorisAwesomeApp\makori.jar, and the data files for it live somewhere in C:\Users\UserThatInstalledIt\Documents\MakorisAwesomeApp.
oh linux, your app might be /usr/bin/makori and the data lives somewhere in the home dir. Config data might live in /etc/.
You don't "ship" your config files, you instead make installers that create them. You can do this part in-app by detecting that the relevant config file does not exist, load in a template (that is a resource, shipped inside your jar, loaded with getResource), and write it out, and tell the user to go look at it and edit it.
I really want a CSV file next to my jars!
Well, that's wrong, so, there are no libraries that make this easy. When you want to do silly things its good that APIs don't make that easy, right?
There are really hacky ways to do this. You can use .getResource to get a URL and then 'parse' this. This breaks the classloader abstraction concept (because in java, you can write your own classloaders and they can load from anywhere, not just files or entries in jars), but you can ask for 'yourself' (MyClass.class.getResource("MyClass.class")), pull the URL apart and figure out what's happening - does it start with file://? Then it is a file, so turn it into a j.i.File object, and go from there. Does it start with jar://? find the !, substring out the jar part, and now you know the jar. Make that a java.io.File, ask for the parent dir, and look there for the CSV.
You have to write all this. It's complicated code that is hard to test. You should not do this.

Create a file link on the fly in wildfly

I have some questions about Wildfly deployment
1.An ear, when deployed in wildfly, is extracted within standalone/tmp/vfs/deployment/ directory. Can I place a file there manually and still access it from web. (I can check it, but as of now I do not have any machine to test it).
Can I create a file and place it there via some program. The reason I am asking this question is that I need to generate some files based on user input and provide the user with a link to that file. One way to do this is to statically link a directory in JBOSS and create the file there(access it using file handlers see this). I just want to know if it can be done at all using something like VFS.

If you need to persist to a file you'd want to create a new file handler, like the link you provided describes, and write the file to that folder. You don't want to try to use that temporary deployment directory. The content is not exploded by default so writing to it would likely fail.
If you don't need to persist to a file you can just use an output stream of some sort and the user will be able to download the file.

where to keep an XML that should be editable and downloadable?

So I have a web app (using apache tomcat server,servlets,eclipse IDE). I wrote code to allow user to edit the XML file via UI. So I used the following code to access the XML through java
String fileName = "/MyXML.xml";
String path = this.getClass().getResource(fileName).toString();
This works fine. I am able to edit the file through UI.
Now I want to let the client download the file. But I am not able to access the file while I am trying to download.
However, if I keep the file inside webapps folder, then I can access the file using the following
ServletContext ctx = getServletContext();
InputStream is = ctx.getResourceAsStream("/MyXML.xml");
(Thanku Mr.MK Yong- http://www.mkyong.com/servlet/servlet-code-to-download-text-file-from-website-java/)
But then If i keep it inside webapp folder, how do I access the file for editing the XML ?
So basically I am either able to edit the file, or I am able to download the file(from webapp folder), or I am able to do both on two different copies of the file. I want to edit the XMl file and be able to download the same. So where do I keep the file and how do I access it?

You should store it in the local resource folder as it is essentially a dynamic resource.
The other thing i recommend is if you know the parameters that will be changed then have a template in resource folder and store the changes in database.
Personally i have it the second way.
e.g.
/yourapp/resource/config_file/xmltemplate.xml
Parameters that can change:
userLocation
folderLocation
colorBase
Stored them in the table:
Table: UserCongifStorage
Columns: userLocation, folderLocation, colorBase
So when i need to use the data from row 1 the logic is:
read in the xml file into a string, replace the variables with data retrieved from database, output it as xml to resource folder.
Then you read for usage.
Hope that helps

If the file is in your 'webapp' folder (I think you mean your application root), then it is already accessiable to everyone by calling hxxp://domainname/appname/MyXML.xml. I would suggest you not to store files that can be edited, inside your app folders, since they will be overwritten if you redeploy your application.
Put them in an external directory and load the contents like you would do with all other files. Doing this you can take control over file permissions easily, too.

Uploading and saving files in JSP

I'm trying to upload images in JSP using Apache Common FileUpload with Spring/hibernate. Uploading of images works well.
My project folder is located by the following path.
E:\Project\SpringHibernet\wagafashionNew\wagafashion
After parsing the request, I'm trying to save the uploaded image into the following folder.
E:\Project\SpringHibernet\wagafashionNew\wagafashion\web\images
I've tried in various ways to get this path but I couldn't succeed.
Specifying a relative path something like the following
File f=new File("wagafashion/web/images/image_file.xxx");
would not work.
Is there a way to retrieve the following path?
E:\Project\SpringHibernet\wagafashionNew\wagafashion\web\images
or specify a relative path with the new File("relative_file_path") constructor?
Am I saving files into a wrong directory? In that case in which project folder files are to be saved?

Maybe.
One way it to ask the the ServletContext to getRealPath("/web/images"), and see if that returns something -- it doesn't have to, but it likely will. If it does, then you can put the images there.
However.
If you're deploying like most folks using a WAR, then all of those images will Go Away as soon as you redeploy, as most containers take the WAR to be deployed and explode it on to the file system. Whatever was in the directory before you did this (i.e. the code and artifacts from when you last deployed) will be going bye bye, and so you will "lose" your images.
You can mitigate this by doing a directory deploy, that is deploy an already exploded directory. Then you KNOW where the application is located (since you put it there). Then it's up to you to sync that directory with your new code as you make changes (notably it's up to you to delete old stuff you don't want any more).
Other than that, different containers have different mechanisms for mapping in an external directory in to the application space. Glassfish has the concept of "alternate doc roots" that you can use. This allows you to have a place out side of the deployment where static stuff can live and still be served by the container, but isn't wiped out when you redeploy.
Finally, you can always do that yourself, stream your own images, etc. without relying on the container at all. This way you can put the images on the file system, in the database, in memory, whatever.

Creating a js file to be accessed by jsp

Alright heres the scenario. I'm creating a dynamic website with Java\JSP\JS. I'm using the Java to access a database and query a table to get information. Instead of passing that query to the JSP, I decided to create a JS file with a class in it with all of that information. (I'm basically building a store locator that will update itself with new stores\locations whenever the user presses a button. Obviously they need to update the table first but you get the point)
And now onto my problem. I'm creating the file by opening a stream. (But first I check to see if the file exists and if it does delete it, because I don't want to keep writing to that same file every time a user clicks the button.)
FileWriter fstream = new FileWriter("test.js");
The location of the file goes to my Eclipse folder directory, obviously. Even doing this,
FileWriter fstream = new FileWriter("./test.js");
put it there. Granted I didn't think it would change but I was testing it out.
The location of the JSP file when the project isn't 'deployed', or testing, its in the workspace location. But when it is 'deployed'
\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\BoomBaby\index.jsp
When I get the location of the JS file its:
/C:/Program%20Files/Apache/lib/
So my question, after all of this, is: How do I save the JS file in the same directory as the JSP file while deployed so I can access it from a JSP file by:
<script type="text/javascript" src="test.js"></script>

You need to build a WAR file. It is basically a zip file with a standardized layout. You put all your jsps in one place, and all your js files in another. Containers like tomcat understand the layout of the war and will run your application automatically. Popular build tools like ant and maven will construct wars for you with little effort.

You can't when deployed as a WAR file. The way this is usually done is, instead of generating a file and referring to it, generate the JavaScript source into the page directly.