I support an application that uses apache poi. Apache poi creates a directory in "/tmp" folder called "/poifiles". System admin runs a job clears up "/tmp" directory. this deletes the "poifiles" folder and I start getting exceptions. When I create this folder manually, everything starts working fine. What I need to do is change the location of "poifiles" folder. I can do this by changing "java -Djava.io.tmpdir=/path/to/new/tmp/folder". However, I want to persist this so I don't have to do this whenever my application restarts or whenever the box is rebooted. What is the best way to set this property so it is permanent?
You could maybe use an environment variable called JAVA_OPTS to set this as a Java system property.
But why not simply create a shell script to start the application that makes the java call and specifies this property?
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Muhammad Imad Qureshi
Joined: Sep 13, 2005
Thanks for your reply. I think JAVA_OPTS idea is good. Since there is no other application running, this should resolve our issue. However, we already have startup scrips with JAVA_OPTS variable and we cannot change these startup scripts. I think I can create a new script and call my startup script from that script and set JAVA_OPTS variable. But that will be overridden by startup script. So I still have my problem.
1) Where POI gets the profiles folder from. Your best bet would be POI's docs or a POI user forum or support email. As a last resort, start a new thread here with an appropriate subject to ask specifically about that. If POI give you a way to specify that explicitly, you can use that.
2) Where Java gets its temp directory from. If POI doesn't have anything else that it uses, it may either be using the java.io.tmpdir system property directly, or it may be using a java.io.File method that in turn uses the property. If POI is using the property directly, and doesn't have anything else that it will use instead, you'll just have to provide the -D arg every time. If it's using a File method, you're still probably out of luck, becsause I don't think there's any way to tell File to use a different directory.
If File.createTempFile is used without a specific directory, it uses the contents of java.io.tmpdir. And this is something you can actually change from your code as well - just call System.setProperty("java.io.tmpdir", myNewPath);. Note that you need to do this before it's used, because some methods (like File.createTempFile) cache its value.
It's been a while since I used POI, but IIRC, POI should create the poifiles folder if it doesn't exist. What is your exact exception?
IMO, changing the tmp folder is not really going to solve much. There is a reason your system admin is cleaning out the temp folder. The temp folder is used by a lot of apps to create junk temporary files. That's why usually you have cron jobs that clean out the folder. The cron job is protecting the machine from getting filled by junk files. Your app is doing the right thing by creating temporary files in the designated temp folder. If you change the temp folder for your app, that means that eventually you will run out of disk space and when the sys admins realise that you are creating temp files in some other folder, they will update their cron job to clean that folder. You will be back to square one
The correct behavior should be that any application that creates a file/folder in temp folder should expect the file/folder to dissapear and recover from it gracefully.
Muhammad Imad Qureshi
Joined: Sep 13, 2005
Thanks for all your replies. I found a script that I didn't know about, where I can modify environment variables so I can now set "java.io.tmpdir" property. but to answer some of your questions, I have looked up poi forums and this problem is resolved by changing this property. But I didn't know how to do it permanently, so I asked here. Changing the location of tmp folder will resolve the issue (though not tested yet) because the new "/tmp" folder will not be cleaned up by sysadmin.