I have a JAVA application that needs to store profile pictures that user uploaded.
My project already finish and works fine.
//in my LOCALHOST i use this path:
File file = new File("C:/myProject/uploads/profile_images");
So, now I want deploy this project, i'm using jelastic environment and the question is:
Where should these files (pictures) be stored in our Jelastic ?
I already tried in the same code but doens't work.
I already tried save the files in WebContent folder, work, but when I expand a new .war file, the files that user has uploaded are overrides.
I read about save files in mySql, is a good idea?
Thank for your atention.
Local filesystem is persistent, but make sure to define in 'volumes' if your node has it to ensure files are kept during image redeploy. You can also use Jelastic storage node, but only worthwhile if you're using multiple application nodes.
See https://docs.jelastic.com/docker-volumes for details about how to use the volumes feature - if your node doesn't have this feature it is not based on Docker (not all node types were converted yet). In that case you can write to the filesystem without any risk of those files going missing (i.e. it will behave the same as a dedicated server or your local dev machine).
Related
We have developed a web application using JSP and Servlet. The server we use is Tomcat 7. We have hired a host (Daily Razor) with "private JVM" to launch the application in production level.
Now, in our application, user can visit a particular form, browse for a file in his PC and upload it to the server. But I have a question there; what is the best place to store these files? Mainly there are 3 types of files so we would like to categorize them into, "Office', "Home" and "Other" and create 3 folders for them. But inside which main folder these 3 folders should be made?
The main important this is that these files should not be accessed via a URL (because then anyone can get them ), but a Servlet can. Apart from that, the location (String) should be saved in our MySQL database so the file can be accessed again without an issue.
We have developed the application using Netbeans IDE so the folder structure is like below.
I look forward for your answers.
Use a java property to specify the directory where the files should be stored, and pass it on to tomcat during start up.
Also, it might be a good idea to separate the files per user.
Possible Solution:
-Duser.data.export.dir=D:\users_export\directory
In your java code, read the property
String property = System.getProperty("user.data.export.dir");
Now lets say for user 'A'
String userName = getCurrentUser();
Path userDirHome = Paths.get(property, userName, "Home");<br/>
Now use userDirHome to store the data.
Suggestion: When you store the file location in the DB, ensure that you do not store the complete path, only store the relative path, like "Home/myFile.txt".
This will help you at a later point in time when, there is any change in the directory where the file are stored.
I have a Java Servlet/JSP application which requires the user to upload an archive file (either .rar or .zip). This archive file is then extracted, and the extracted files are parsed. After parsing the files, the data in them is added to the database and the files are deleted again.
On my local machine, this works perfectly, since you just use the filesystem provided by the OS. But now I'd like to run this application on Heroku and I'm unsure on how to do the file uploads.
Since these files are user specific, and not permanent, my initial thoughts were that I could just use the ephemeral file system provided by Heroku and I do not require the use of S3.
At the moment, my application runs on only 1 web dyno and no worker dyno's but in the future this may get scaled to multiple web dyno's, depending on the amount of users that are going to use it.
Can I use the ephemeral file system for my specific use case, and will it scale properly?
I am currently writing using ServletFileUpload, and am writing to java.io.File; Can I just change the path of my java.io.File to a path in the ephemeral file system? What would be an example of such path?
I guess you can use the ephemeral fileystem in your specific case, as it's just a temporary usage for parsing the file.
You can use the /tmp directory but keep in mind that the file will be destroyed after the request is complete.
This is discussed in this post https://stackoverflow.com/a/12416923/476782
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.
I've searching for this for a while now online (Google, and StackOverflow), but haven't yet come across this question. Maybe my query is not correct (please redirect then!)
I've developed and set up a WebApp on TomCat 6 under Linux. Tomcat isn't running in a virtual host environment yet, I have full control over server. Therefore, .war file is saved to Tomcat's standard deploy dir. The issue I have is with images: different web services provide differently-sized images which need to be presented in uniform sizes.
I download them and resize them without problems, but have to store a local copy of the image as this takes some time if done real-time, plus a lot of bandwidth waste. I don't save them under the .war's temp dir under Tomcat, due to case where a server shutdown would force me to reload all images.
I have created a different directory under /home/username/images, which I then serve under a different subdomain through regular Apache, and the HTML code generated in the .jsp is simply a correct URL to the file. Works great if the image doesn't exist. However, due to permission issues, the Tomcat instance cannot remove or overwrite files already created, even though I've marked the folder where images are stored with 777 permissions. As an aside, I don't see need to give it 777 perms, but with 755 (for example), I had permission issues even when trying to save a new file.
So: is there a better solution (I considered database, but the images dir is now 250mb, and I see no need to overload the db so much)?
Don't store the images in the database. Your /home/user/www.example.com/resources approach is in the correct direction, just sort out the privileges issue. Make sure the path is in a group where the user who runs tomcat (tomcat?) belongs in and reduce the 777 because it's too broad.
It is a little unclear as to whether tomcat and another user are writing, or only tomcat.
If it is only tomcat, the directory in question should be owned by tomcat, and the permissions can be either 750 (setting the group to match apache's group) or 755 (the group doesn't matter, anyone on the machine can read the files).
Note that if some other user is writing files, you have to be trickier. In that case, you need 775, user tomcat, group tomcat, and put the additional user(s) in the tomcat group. If those users are in multiple groups, you can use the group sticky bit on the directory to force the group to remain tomcat. In this case, anyone on the machine can read those files.
The documentation for chown and chmod should be of great help.
(Yes, I do realize that this question is very old, but the same principles apply, and no one seemed to give a clear answer).
What specifically is happening with the permissions? Tomcat will be running as some userid (say tomcat1) and will be creating files presumably owned by the same user (tomcat1). If your files are being created with a different owner, then that will explain why you can't overwrite existing downloads and you'll need to work out why the ownership is differen. If it's not ownership, then are the files being created without write permission to the user. In this case, consider explicitly setting the permissions on each file saved to allow the owner to write to it, or change the umask of the user account.
We have to make a Java application demo available on Internet using JWS. It goes pretty well; all that's missing is making working directory files available for the application.
We know about the getResource() way... The problem is that we have different plugins for the same application and each one require different files (and often different versions of the same files) in their working directory to work properly. So we just change the working directory when we want the application to have a different behavior.
Currently, the demo is packaged in a signed jar file and it loads correctly until it requires a file from the working directory. Obviously, the Internet users of this demo don't have the files ready. We need a way to make these files available to the WebStart application (read/write access) in its working directory.
We've thought of some things, like having the application download the files itself when it starts, or package them in the jar and extract them on startup.
Looking for advices and/or new ideas. I'll continue working on this... I'll update if I ever find something reliable.
Thank you very much!
I said I would share what I found in my research for something that would fit my needs. Here's what I have so far.
I have found that the concept of current working directory (CWD) does not really make sense in the context of a Java Web Start (JWS) application. This had for effect that I stopped trying to find the CWD of a JWS and started looking for other options.
I have found that (no, I didn't know that) you can refer (using getResource()) to a file in the root directory of a JAR file by simply adding a '/' in front of its name. ("/log4j.properties", for example.) The impact of this is that I can now take any file which is only referred to in a read-only manner in the root of that JAR file (which is really only a ZIP file). You can refer to any file in the root of the JAR file using AnyClass.class.getResourceAsStream. That rules out the problem with read-only files required to run the application, at the cost of a switch in the code telling whether the application is run from a valid CWD or from a JWS context. (You can very simply set a property in the JNLP file of the JWS application and check if that property is set or not to know where to look for the file.)
For write-only files (log files in my case), I used the property , adding a directory with the name of the application: <user.home>/.appname and added log files to it.
Read/write files (which I don't have in my case) would probably simply go at the same place than write-only files. The software could deal with uploading them somewhere if needed, once modified, I guess.
That's the way I deal with the problem for now.
Note there is a service you can explicitly ask for, to get file access to the computer (unless you go all the way and ask for full access (which requires signed jar files)).
Then you need to determine where these files need to go - basically you have no idea what is where and whether you may actually write anywhere. You can create tmp-files but those go away.
Would a file system abstraction talking to the JNLP-server do so you store the users data on the server?