• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is Java Servlet able to read Tomcat/bin directory more easily

 
Eric Racin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am upgrading from Server 2003 to 2012. A Java Servlet that worked for 5 years is being upgraded to Tomcat 7 and JDK 8. I access the local C: drive file with

I get the error msg
Error: java.io.FileNotFoundException (the system cannot find the file specified)


Perhaps the Servlet could read from Tomcat7/bin better? Perhaps the permissions for that path are accessible for Servlets, since Tomcat is Web Container?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65522
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adjust the file system permissions correctly. Don't go polluting tomcat's folders as a band-aid.
 
Amit Ghorpade
Bartender
Posts: 2856
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In addition to what Bear said, I would suggest using a different drive than C: for your application. My opinion is C: (or primary partition) is the OS and programs' home ground.
Even better, get rid of absolute paths and come up with relative ones if feasible/available.
 
Eric Racin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You both are right, I should change things. But given that I can't (for reasons I won't go into), are there more read/write privileges given to the Tomcat/bin directory? I assume that this is the case since Tomcat is the web container. Thanks.
 
Tim Holloway
Bartender
Posts: 18412
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should not be writing application data files into the Tomcat directories and you should NEVER write/update files in an application WAR. In the case of Tomcat's directories you could lost stuff when Tomcat gets upgraded and you are opening up Tomcat itself to potential damage. In the case of a WAR, depending on how the WAR was deployed, it may actually be physically impossible to write to the WAR (because it's not a directory, it's a ZIP file). And even if you could, an application update could nuke your data.

The java.io.File class has methods for creating and using tempfiles. Those methods may be used freely in webapps, and in fact since you can make a file self-deleting, they're an especially good fit for webapps.

The temporary directory that is used is established by the JVM itself, and the default in Tomcat's case is that it will use its own local temp directory (TOMCAT_HOME/temp). Yes, this violates what I just said but since Tomcat's controlling it, it's OK. You can configure Tomcat to use an alternate directory if you want to put the temp files someplace where there's more room for them or whatever.

Normally for more permanent (non-temp) files, I supply a JNDI parameter as part of my Tomcat's webapp Context that contains the absolute filesystem path of the directory that will be used. That avoids having to hard-code the path and is especially useful when the development machine runs Windows (C:\mywebapp\files) but the production machine runs Solaris (/var/lib/mywebapp/files).

All webapps run under the same userID (and hence permission set) that Tomcat itself does. So the directory in question needs to be assigned rights for the tomcat userid.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!