Java webstart - application deployment directory
Hi,
Applications deployed via Java Webstart (using JRE 1.4.2) were installed under :
\Documents and Settings\username\.javaws\cache\http\........
I am trying to test my application deployment with Java 6 - and - I cannot find the directory in which the application is deployed. But my application does come up correctly.
Along with the application we are distributing some data files (as XML) - which were getting deployed in the same directory as the application (in Java 1.4.2).
But with Java 6 - the files are not getting distributed - and I get exceptions when marshaling the files using the castor APIs.
Question is: Is there a way to distribute files - so that the Webstart automatically handles it? If no - what is the work around?
Thanks in advance for any suggestions/pointers.
[837 byte] By [
hrtpa] at [2007-11-27 3:50:33]
# 1
> Along with the application we are distributing some data
> files (as XML) - which were getting deployed in the same
> directory as the application (in Java 1.4.2).
> Question is: Is there a way to distribute files - so
> that the Webstart automatically handles it?
The single best way is to jar them up, add them
to the classpath of the JNLP application and refer
to them using Class.getResource().
This way, the application always gets the correct
URL, and web start downloads and caches the
resource transparently (Works JWS 1.1 through
1.6+ using 'lazy' or 'eager' downloaded jars in
'sandboxed' through 'full privileges' app.s).
If, for some reason, an application requires files
to be in a specific place (a DB data file, input for
an external process, launched using the JWS
app. , etc.), it is best to (1) put the file in a specific
place, then (2) remember where to find it.
1) Use an installer element to launch an utilitly
that gets a path from (best) "user.home" (e.g.)
"user.home"/com/ourpackage/the.data,
download the file using whatever means you
wish and put it on the local file system, then ..
2) (assuming you prompted the user to put it
there, but they chose to put it somewhere else)
store the path using the PersistenceService*.
* e.g. http://www.physci.org/jws/#ps
# 2
Thanks Andrew for the tips.
Is there a way to use the FileOpen & FileSave in silent mode (i.e. I do not want the user to specify the name & directory)?
I will try to look into the option where I can jar the data files - (in our case the data files can be downloaded whenever the user needs it.)
We do not want the user to know where the data files are located - although an intelligent user can always figure out.
Right now - we get the path to store the files using:
***************************************************
java.io.File file = new java.io.File(MyClass.getProtectionDomain().getCodeSource().getLocation().getFile());
strpath = new java.io.File(file.getParent()).getAbsolutePath();
***************************************************
We append the filename to the above path & store the downloaded data in that file. The data is mapped to the fields in the GUI screen.
The above piece of code returns (in 1.4.2)
C:\Documents and Settings\testuser\.javaws\cache\http\Dwastest.dot.state.xx.us\P80\DMappdev\DMapp
The same piece of code returns (in 1.6)
C:\appdev\app
Since the above directory is not present - I get an exception when trying to write the file to the location.
Our application is signed(trusted) - so may be I will have to create the directory myself and store the files.
Any suggestions?
As of now - I am forcing users to download Java 1.4.2 with Webstart - which works fine. But I need to find a solution which fits both needs.
Thanks again...
hrtpa at 2007-7-12 8:54:29 >
# 3
> Is there a way to use the FileOpen & FileSave in
> silent mode (i.e. I do not want the user to specify
> the name & directory)?
No. but given your application is..
> ...signed(trusted) -
You might use the JNLP API ExtendedService
(in 1.5+) to open the file directly..
For an example of FileOpenService/FileSaveService
and ExtendedService, see..
http://www.physci.org/jws/#fs
OTOH, given the app. has full trust, you might
silently put the files in user.home, using an
initial sub-directory name that starts with a '.'
to make it invisible to most Windows (at
least) users. Then use the normal file methods
to access it at the 'factory preset' path.
> ..so may be I will have to create the directory myself and store the files.
Yes, it seems that wold be the best strategy
to pursue.
