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.
Related
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.
I am making a Spring (not Boot!) project right now, with Maven. The user can upload a file, then I store it in the file system. When I start the application, I create a folder with a method annotated with #PostConstruct. I have already tried two ways: create the folder in the same level as the src and target folder, or create it in the target/tomcat folder (I used the ${catalina.base} property). I want to do some conversion on the uploaded file, basically convert it to JSON, and also store the JSON file. Then I want to use these two files inside JSP pages: when the user executes a GET request, my application will return the path of the files, and I want to use the content of the JSON with JavaScript.
So my question is basically: what is the best place to store these files, if I want to use them later for any purpose, and I dont want to use absolute paths. I saw some example when the code creates a folder like: "C:\folder", but that looks weird for me, relative is much better in my opinion.
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.
Task: Copy Folder and contents from one vdi to another vdi. This application is internally facing within the company.
Method:
In jsp have user browse for folder
The folder selection is in a text box, the folder path is passed into an action class
The folder path is placed into a teradata table
A script is called to query the table for the source path and target path (pre-determined) and make the copy
Due Dilligence: So far I have tried the <input type="file", which selects a file, not a folder. Also, the file path is not passed through due to security reasons. I have read other possible solutions but none work.
Question: Are sevlets a viable solution, and if so, how do I create one?
I'm going to go with no. There are several reasons for this.
A Java Enterprise Edition application (be it a Servlet or Java Server Page) is not supposed to access the file system directly.
It is inherently unsafe to expose internal infrastructure through an external website.
I think you need to break it up a bit more.
Save a list of shares the server has access to in a data store of some sort, like a new teradata table or for a quick proof of concept plain text file (if you're on Linux you can use the output of something like showmount -e localhost).
Let the user pick the src share from a combobox or something similar.
Continue from your step 2.
This gives you two immediately obviously advantages, which may or may not be relevant.
You can use the system without having access to the physical shares.
You can add metadata (like description or aliases).
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.