looking for a long time on the network, did not find the complete Shema document of JNLP. Here to find some information, record, about the platform to record jar package problem.
I. Configuration issues
The Java Web Start Resource tag
The "Resource" tag in the Java Web Start descriptor has two key elements to allow efficient Java application. One important attribute of the resource tag is the "OS" attribute. This attribute is allows to specify specific platforms for the deployment of your application. Options in the "OS" attribute can is "Windows", "Linux", "Mac os X" etc.
The next relevant resource attribute is the "arch" attribute. This attribute allows is for the specification of the processor architecture. Relevant values for the "arch" attribute include "X86″and" Amd64″ (even for Intel 64bit). Additional "Arch" values are seen below in the Web Start JNLP code.
The following is a example a Web Start JNLP file ("TESTBROWSERALLPLATFORMS.JNLP"):
<JNLP spec= "1.0+" codebase= {Set the base URL here is where all jars stored. For example http://www.webrenderer.com/webstart/} "href=" TESTBROWSERALLPLATFORMS.JNLP > <security> < all-permissions/> </security> <resources> <j2se version= "1.4+"/> <jar href= "Testbrowser.jar" /> <jar href= "Webrenderer-swing.jar"/> </resources> <resources os= "Windows" arch= "AMD64" > < Jar href= "Webrenderer-swing-windows64.jar"/> <jar href= "Corecomponents-swing-windows64.jar"/> </ resources> <resources os= "Windows" arch= "x86" > <jar href= "Webrenderer-swing-windows32.jar"/> href= "Corecomponents-swing-windows32.jar"/> </resources> <resources os= "Linux" arch= "AMD64" > <jar
href= "Webrenderer-swing-linux64.jar"/> <jar href= "Corecomponents-swing-linux64.jar"/> </resources> <resources os= "Linux" arch= "i386 x86" > <jar href= "Webrenderer-swing-linux32.jar"/> <jar "href=" CorecomponenTs-swing-linux32.jar "/> </resources> <resources os=" mac\ os\ X "arch=" x86_64 "> <jar href=" Webrenderer-swing-osx64.jar "/> <jar href= corecomponents-swing-osx64.jar"/> </resources> < Resources os= "Mac\ os\ X" arch= "i386 x86" > <jar href= "Webrenderer-swing-osx32.jar"/> <jar "href=" Corecomponents-swing-osx32.jar "/> </resources> <application-desc main-class=" Testbrowser "/> </
Jnlp>
Second, the dynamic generation problem:
(If the Tomcat version is old enough to configure Conf/web.xml, add
<mime-mapping>
<extension>jnlp</extension>
<mime-type>application/ x-java-jnlp-file</mime-type>
</mime-mapping>)
Code:
PrintWriter out = Response.getwriter (); <span style= "color: #ff0000;"
>response.setcontenttype ("Application/x-java-jnlp-file");
</span> out.println ("<?xml version=\" 1.0\ "encoding=\" utf-8\ "?>");
Out.println ("<jnlp spec=\" 1.0+\ "codebase=\" http://localhost\ "href=\" report/jnlp/openfile.do\ ">");
Out.println ("<information>");
Out.println ("<title>JNLP</title>");
Out.println ("<vendor>Hust</vendor>");
Out.println ("
Third, the dynamic generation cache problem:
In practical applications, due to JNLP and JWs itself bugs, in some cases, background Jar program update upgrade, user side start JNLP not be able to get updates, need to forcibly empty JWS cache, this is certainly not the general user understand. There is also a situation where the contents of the JNLP file are changed as a result of the change in the jar package of the ERP itself (for example, the increase or decrease). At this point, the user side of the machine must be aware of JNLP changes and first update the JNLP. In many Java versions (such as the previous version of Jre6, such as Jre6 Update20), it was not possible to update successfully due to some potential bugs, causing the program to fail to start.
How to solve this situation. It is an effective method to adopt dynamic JNLP.
The idea of dynamic JNLP is to generate a JNLP file dynamically through a JSP or servlet on the backend of the server, instead of placing a static, invariant JNLP file. In this way, the JNLP file content can be dynamically generated by the logic of the background application: What jar packages are needed, what JRE versions are needed, and so on.
Take JSP as an example. In this JSP, the first thing to pay attention to a number of technical points is: To set this page not to be cached by the browser, placed JNLP content changes can not be updated in time; the next step is to set the MIME type so that the browser thinks it is a jnlp file for download execution rather than directly appearing in the browser You can achieve these goals by setting up response:
Response.setheader ("Pragma", "No-cache");
Response.setheader ("Expires", "0");
Response.setheader ("Content-disposition", "filename=\" bb.jnlp\ ";");
Response.setcontenttype ("Application/x-java-jnlp-file");
One issue to note is that when generating JNLP files dynamically, be aware that the href tags in the jnlp file are not set . Why, then? Take a look at the JNLP format document that says:
Http://lopica.sourceforge.net/ref.html#jnlp
The JNLP file ' s one and only root.
Attributes
Spec=version, optional
Specifies what versions of the JNLP spec a JNLP file works with. The default value is 1.0+. Thus, can typically leave it out.
Version=version, optional
Specifies the version of the application as the version of the JNLP file itself.
Codebase=url, optional
Specifies the codebase for the application. Codebase is also used as base URL to all relative URLs in href attributes.
Href=url, optional
Contains the location of the JNLP file as a URL. If you leave out the href attribute, Web start would disable the update check on your JNLP file, and Web start would not Tre At each of the new JNLP file as an application update–only updated jar files. Leaving out href usually makes only sense if your JNLP the file is created dynamically (which, throug a cgi-script, for exam PLE) and if your JNLP file ' s arguments or properties change from the request to request (user to user).
Note, which is the Java Web start needs href to list your app in the Web start Application Manager.
Can be seen in the dynamic generation JNLP do not set the href, so that every time the browser will be downloaded JNLP file content, otherwise it may be cached, unable to update the program in time.