Many of you might use Oracle’s JNLP Download Servlet, delivered with JDK in jnlp-servlet.jar. One of the nice features of this servlet is the automatic replacement of variables at runtime, e.g. codebase and context. However, the existing documentation does not reveal all of these replacements. While searching for a solution where I need to put the server name into the JNLP file, I also examined the source code of JnlpDownloadServlet. And voilá: the feature is already there but not documented.
Here is the complete list of replacements that the servlet does for you while delivering a JNLP:
$$name: will be replaced by the name of the URL file requested (without path, e.g. myfile.jnlp)$$hostname: will be replaced by the servername as given in the HTTP(S) request$$codebase: will be replaced by the codebase (request without URL file: http://my.server/appname/somedir/)$$site: will be replaced by the protocol, server and port, e.g. http://my.server:8080
I hope you’ll find that useful next time you look for a solution to deliver WAR files to individual servers with the specific servername in its JNLP file.
3 replies on “Undocumented Java WebStart Features”
Erm … nice … I did not test this but … and how could that possibly work with signed JNLPs?
According to the tutorial here … the same JNLP file must be inside the main JAR.
Hi Lucas,
hmmm, we didn’t do that ever. The JNLP was created by tomcat servlet whereas the JAR was signed as usual (not containing the JNLP). We didn’t notice any problem with our customers by not following the described procedure.
I noticed that the article you referenced is written just a few days ago (Oct 2013). So I can only assume that WebStart has changed some specifications lately. Perhaps one of my readers can share his first experiences. 😉
Thanks for the comment
Ralph
It’s been a while since the last post, but for future visitors I want to share my experiences.
In case you need to keep codebase etc. dynamic, you can use an APPLICATION_TEMPLATE.JNLP instead of APPLICATION.JNLP in the JNLP-INF directory of the jar (follow the official tutorial for more information). This copy is used to compare the downloaded jnlp file in order to validate it as “signed”. But you can wildcard some things with “*”. This way you can still validate jnlps with different codebases against the same template in your jar.
The official tutorial has a tiny example. Keep in mind, though, that you cannot wildcard “value” in property tags (for some security reasons). We needed to convert one dynamic property to a command line argument.