I'm trying to implement something that would pass a dynamic url to my JWS app as it launches, but should also know when it's being launched locally (from the desktop) as not to load the last dynamic url. If it's launched locally, I want it to prompt the user for the file or url to load. If it's launched via the web, the location will be supplied.
So, what should I use to forward the information to the JWS app?
So far, I've only gotten the <property> tag to work, by using this in my code.
but when I launch it from the desktop, I still get the value - it retains it from the last dynamic web launch.
I have a visualization app that we're deploying via JWS. I'm trying to tie it into a web page that will call my jnlp along with supplying the url to the file my app is suppose to open. So I thought we could dynamically build the jnlp to supply the link to the web service query that will supply the data to my application. However, my app can also open local files if the user has any. I'd like the user to be able to launch the JWS app from the desktop and be prompted for the file to load, but if they launch it via the web site, it's already being told what file to load, so it just opens it.
So you've got two different versions. (One version hard-codes the file to load, the other allows the user to choose.) That would require two different JNLP files.
When you run a JWS application from a website, that causes it to be downloaded and cached on the user's machine. The application can later be run from the cache. It can also be designed so that if there's a new version on the website, it will download and cache that new version. This means that "run from the website" and "run from the user's machine" aren't really meaningful categories in Web Start.
Was thinking there might be a way to validate the last file. For example, perhaps I could write a jnlp file with the url and timestamp as variables. I then write that information to a local file or some other location (PersistantService or muffin). Then if the program is launched again and the jnlp url and timestamp equal that stored in the local file, then it is invalid and thus being run from the local system and not the web.
Yup, sounds like that might work. Or you might still consider the two-configuration option: the first provides a URL from the web site, which as you observer will always use that URL no matter where it's run from. The second wouldn't provide any URL, and so it would always prompt the user no matter where it was run from.
Hey, of course your deployed your JNLP file to web application. So do one thing to achieve your purpose you need to crate dynamically JNLP. So for that first you have to required one JSP which actually create Dynamic JNLP for you.
For that create one Servlet which actually set parameters what you required and then pass request to your JSP using,
After setting all your request param create your JSP like,
So, rereading Paul's comment again. Can I create two jnlp files for the same application? One that is dynamic, which by default does not have a desktop icon, and loads the file based on the existence of a "property" definition in the jnlp file. Then a second jnlp file that is static, does specify a desktop icon and menu shortcut, and does not contain the "property" definition, thus making the application prompt the user for the file to import. Does this sound correct?
Well, I tried this on my VM and it worked.. then I get into the test environment and it doesn't work. I have two JNLP files, one is dynamic and does not have an href. The other is static and contains the <desktop /> tag to indicate a shortcut. The shortcut is never getting created if I run the static jnlp file. It's the same code base.. what's going on?
Jeff Gent wrote:It's the same code base.. what's going on?
Oh yeah, I remember this... I wanted to have six JNLP links which differed only in the startup parameters provided to the app. But if all six JNLP files referred to the same jar, then the first one which somebody used would cache the jar locally and the other links would use the cached jar and the parameters from the first one. I had to create six identical copies of the jar with different names, one for each version of the app.