On Mar 24, 2012, at 11:34 AM, John Caron wrote:
Sorry for the delay in responding.
Both ideas below sound interesting. Im not clear exactly how you are using the jnlp. Are you doing the same thing the TDS does to allow viewers to start up with a particular opendap dataset URL?
Well, probably I'm doing the same thing the TDS did a some point in the past. :)
Currently I deploy Hyrax with prototype JNLP files for each application (Well not AutoPlot, as I described below). Dereferencing a web start link associated a dataset causes Hyrax to grab the prototype JNLP, edit the command line arguments for the webstart application, and then return the file to the requesting client.
Can you send me an example Hyrax URL that fetches the jnlp?Here's the viewers page for a dataset served on Hyrax:
The IDV link returns a useful JNLP because the the JNLP basically points to the latest version and the resources are described in a file held on the IDV server. So when the update the version and change the jar dependancies the "world" doesn't have to get a new JNLP file.
The ToolsUI link returns a stale JNLP because the version referenced by the prototype JNLP file bundled in Hyrax references an older version of the NetCDF ToolsUI, which depends on a file that is no longer hosted at the UNIDATA site:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://www.unidata.ucar.edu/software/netcdf-java/v4.2/webstart/bufrTables.jar
Does that help?
Also I edited my spastic description of AutoPlot…
On 3/15/2012 1:04 PM, Nathan Potter wrote:Greetings
I have some questions regarding the way that IDV and ToolsUI are deployed via webstart. I have been caching the prototype .jnlp files in my distribution and modifying the arguments as needed on a per request basis. This implementation lacks flexibility when the application host site upgrades to a newer version (and removes the older one). I see that on motherlode the IDV jnlp bundle now references a "current" version of the codebase (http://www.unidata.ucar.edu/software/idv/current/webstart) and that the resources (jar files) are loaded based on content held at the application site: http://www.unidata.ucar.edu/software/idv/current/webstart/IDV/idvbase.jnlp
This seem like a much more flexible plan. Is it something that will also be done for NetCDF-ToolsUI?
Alternatively, someone pointed me at the way that AutoPlot handles it's jnlp generation. They host the application files and a cgi that you pass the arguments to as part of the query string, it hands back a JNLP with the arguments filled out and pointing to their most recent version of the AutoPlot application.
Any thoughts about this?
Alternatively, someone pointed me at the way that AutoPlot handles it's jnlp generation. They host the application jar files and also a cgi to which you pass the command line arguments as part of the query string. The cgi responds with a JNLP file in which the command line arguments are filled out, and all of the resources are pointing to their most recent version of the AutoPlot application.
= = = Nathan Potter ndp at opendap.org OPeNDAP, Inc. +1.541.231.3317
_______________________________________________ thredds mailing list address@hidden For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ thredds mailing list address@hidden For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/= = = Nathan Potter ndp at opendap.org OPeNDAP, Inc. +1.541.231.3317
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.