Home/ Questions/Q 8374817
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T15:00:45+00:00

I’m trying to upload images in JSP using Apache Common FileUpload with Spring/hibernate. Uploading

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0