Java Web Start

Java Web Start (JWS) is a new technology provided by Sun to deploy and release Java programs through the Web. It can be used to publish applications or applets, it was awarded the world's best Java technology innovation award last year. It only downloads the program during the first running. All future tasks will be handed over to JWS, including automatic version update and maintenance. This is what we once dreamed of. The program runs on the client (local operation, of course, there is enough speed), but you do not need to install and configure the client, or consider maintaining the client after version upgrade, this is one of the benefits that JWS provides to us. OK. Now let's take a look at how to play with JWS. This article only describes how to release the application.

System Environment: win2000professional + tomcat3.2.1 + jdk1.3.

I. Introduction to JWS

JWS is mainly used to deploy your applications over the network. It is secure, stable, easy to maintain, and easy to use. Users can access the site where applications are deployed using JWS to download published applications. They can run both online and offline applications through the JWS client. For the same application, it is downloaded at the first run. During each run, the JWS client automatically detects whether version updates exist and automatically downloads the new version, run the current local version without any updates. All the troubles are handled by JWS. Okay. Next we will build JWS step by step.

2. Build a JWS-supported Web Site

Step 1: Your Tomcat 3.2.1 is running properly

Step 2: Find the Web. xml file under tomcathome/conf and add

Application/X-Java-JNLP-File

To support JNLP files.

3. Deploy the application

Step 1: Develop the application you want to publish

Step 2: pack the application and all resources used into one or more jar packages.

Step 3: If your application does not use any local resources on the machine that runs the application, your application can be deployed.

Step 4: If your application uses the local resources of the machine running the application, your application must be signed before publishing.

Step 5: how to sign an application

1: first, make sure that you have fully installed the Java2 environment. The keytool is located in the bin directory of j2se SDK. This is generally not a problem.

2: In the DOS state, enter the directory where the jar package of the application to be released is located. Run the following statement:

Keytool-genkey-keystore mykeystore-alias same stest

It will prompt you to enter the user name, password, and so on. Just enter the password as prompted, but remember the password. After running, it will create a file named mykeystore in the current path.

3: If you want to view the content of the generated mykeystore file, you can use the following sentence:

Keytool-list-keystore mykeystore

It should be shown as follows:

Keystore type: jks

Keystore provider: Sun

Your keystore contains 1 entry:

Optional stest, Tue Nov 23 19:29:32 PST 2001, keyentry,

Certificate fingerprint (TEST ):

C3: A9: CD: F3: D3: AC: 4d: 3f: 3C: 5b: AF: 9e: Cf: 0d: 46: 5C

4: sign the jar package of the application you want to release. Run the following statement:

Jarsigner-keystore mykeystore yourtest. Jar named stest

Yourtest. jar is the name of your jar package. You do not need to modify it unless you modify it. You will be prompted to enter the password, which is the password you set when generating the mykeystore file.

Step 6: deploy the jar package of the application.

1: create a directory named deststest in Tomcat's webapps.

2: create directory apps, META-INF, WEB-INF under deststest

3: create directories images and Lib in apps

4: Merge manifest. MF into the META-INF

5: Pull web. xml in the WEB-INF

6. Export the prepared jar package to the lib directory.

4. jsp page

Step 1: Compile the page index. jsp for Web access as follows:

 

Step 2: add the JWS client code in JSP to check whether the accessed client has been installed. For example:

 

V. JNLP File

Step 1: Let's write the JWS core configuration file JNLP. With this, we can associate the above parts to make JWS run. The JNLP file conforms to the standard XML syntax and is essentially an XML file. Of course, the best way to write it is to rewrite the JNLP that has been written. An example of deststest. JNLP is as follows:

Spec = "1.0 +"

Codebase = "http: // your IP: 8080/Hangzhou stest/apps"

Href = "maid. JNLP">

Your name

JWS Test

 

Step 2: Some Key syntaxes of JNLP

Element

SPEC: It must be version 1.0 or later. It must be 1.0 + and does not need to be modified.

Codebase: The resource URL. JNLP points to the start point of each connection and needs to be modified on its own.

Href: The storage location of the JNLP file relative to codebase, and the full name of the JNLP file, which must be modified by yourself.

Element

Title: simple title of the published application, which must be modified by yourself.

Vendor: Publisher Information. You can write your name and you need to modify it on your own.

Homepage: stores the URLs of documents related to the application, such as the help file.

Description: The description of the application. There can be many or none.

Icon: After you download your application, the icon URL displayed in JWS should be in GIF or JPEG format. Modification is required.

Offline-allowed: select an item to allow users to run applications offline. This option is generally available and does not need to be modified.

Element

If not specified, the application is not allowed to access the user's local resources by default, that is, the application runs in a sandbox.

If this parameter is set, the application is allowed to access the user's local resources. This value is usually set.

Element

Element

Main-class: Main class for starting an Application Program

: You can set multiple parameters when an application is running. One parameter is used for each parameter.

So far, you have built all the components that run JWS.

6. Complete release and Test

We have prepared the jar package for the application to be released and the JSP file to be accessed and the core JNLP file on the server.

Step 1: Create a new directory JSP under mongostest. Import index. jsp into the JSP directory.

Step 2: directly upload the JNLP file to the apps directory.

Step 3: Enter http: // localhost: 8080/javasstest/JSP/index. jsp in the browser to access the JSP page. Stest should appear on the page.

Step 4: Click Export stest, connect to the export stest. JNLP file under apps, start JWS, and start downloading your published application.

Step 5: After the download is completed, run it directly. In the future, you can also directly run the applications downloaded from the JWS client.

Congratulations! You have already begun to enjoy the fun of JWS.

7. FAQs

As mentioned above, you will be able to understand the ease of use of JWS. Maybe things are not that simple. With my use experience, there will be many problems. Here we will pick a few frequently-occurring problems and provide corresponding solutions so that you can avoid detours, and enjoy more fun.

Problem 1: JWS cannot be run. JNLP files are displayed in the browser just like common XML files.

Solution: Modify the Web. xml file in the publishing program path in Tomcat.

Add

Application/X-Java-JNLP-File

To support JNLP files.

Problem 2: failed to download or download resources

Solution: uninstall the JWS client, delete the items related to JWS in the registry, delete the Java Web Start directory under program files, and reinstall JWS.

Question 3: There are unsigned files in the downloaded Resource

Solution: 1. Ensure that all jar packages and other resources have been signed.

2: make sure that there is no Chinese name in the entire resource. It seems that the signature tool does not support Chinese naming file names, so it does not sign in. This made me feel depressed for one afternoon.

3: Check the keystore stest In the meta-INF path of the signed JAR package. SF (named after alias when you sign the file), which lists all signed files in detail to analyze the cause of signature failure.