ExtendedService and FileOpenService don't use same default path.
I have an application (unsigned) that saves progress to a file chosen by the user using the FileSaveService.
I store this location (specifically location.getName()) using the PreferencesService so that the most recently saved file can offered at startup of the next session.
I therefore have to use the ExtendedService to open the file on next startup.
During testing I am launching my application at the command line using javaws <jnlp>, rather than deploying to a webserver, which could be what's exposing this problem:
The FileOpenService seems to return a FileContents whose 'name' is relative to the 'home.dir'.
The ExtendedService.openFile() call seems to look for files relative to some other location, probably the working directory of my IDE, or of the .jnlp file.
So, when I try to openFile() passing the FileContents.getName() stored earlier it fails to find the file.
JNLP won't give me access to System.getProperty("user.home") so I can't hint this to openFile().
Has anyone experienced this problem? Can anyone suggest a way around it?
# 1
A java File object takes a path specification that is either fully qualified or not.
If not fully qualified, it is relative to the "curent" directory. (which is reflected in the value of the System Property "java.dir")
Relying on the curent dir in web deployed applications and plugin applets is problematic, since it depends on the curent directoryof the process or shell that invoked the browser, or javaws if invoked directly. That is why you are getting differant results when running from the command line.
The security group has prevented up from exposing the system property "java.home" to an untrusted application or applet, but perhaps we could solve this problem by setting the System Property "java.dir" to the value in "java.home".
This way relative paths would be consistent in a web start app or plugin applet.
/Andy
# 2
> The security group has prevented up from exposing the
> system property "java.home" to an untrusted application
> or applet, but perhaps we could solve this problem by
> setting the System Property "java.dir" to the value in "java.home".
That sounds good, but while you are thinking
of such things, I will add that I would like to
see an option to 'suggest' to the file chooser
to use paths according to system properties..
e.g. in addition to..
FileOpenService.
openFileDialog(pathHint, extensions)
..add a new overloaded method..
FileOpenService.
openFileDialog(pathHint, extensions, boolean pathIsProperty)
..to suggest a new use like..
fos.openFileDialog("user.home", xtns, true);
The intent being that the web-start client inserts
the correct path for user.home, without ever
exposing it to the original application.
Is this doable?
# 3
I've just realised that this problem is far more simple and serious that I thought.
It's nothing to do with how I launch my app, or indeed what the JVM default path is.
FileContent.getName() only returns the file name, not the path at all.
So it's impossible to re-open a file that the user referred to using FileSaveService. There is no way to know what the path of that file was.
If my user navigates to some location on their harddrive and chooses a file to save to, all I get back is the name they chose. So in a later session I have no way of offering them the choice of re-loading a previously saved state.
Am I mistaken? I hope so! Is there some way to get the fill path of the FileContents that I have missed?
