java.lang.Object | +----java.lang.ClassLoader | +----WebRun
Copyright 1998-2001 Michael Sinz. All rights reserved. | ||
---|---|---|
|
||
The front end is run as the main Java class using any Java 1.1 or later runtime environment (RT, JRE, or JDK). It may be compiled as part of a package or outside of packages. It does not depend on its package name in any way other than it is the location where we place our Java tools.
The code was specifically written in such a way as to only require a single class file (in addition to Java) to be on the user's system. Thus some of the strange constructs to do the AWT windows for the password entry and for the status display.
Since the user may not wish AWT interactions, WebRun does not require it. If you do not ask for the authorization requester or for status window display, WebRun will run without AWT interactions which means it can run without any AWT requirements (such as without X on a Unix system). See the -R switch below for details.
The syntax is simple:
java [
jdk_options]
[package.]WebRun
[
webrun_options]
your.class.name
[
your_arguments]
or
java [
jdk_options]
[package.]WebRun url
The first form provides for local configuration of what will run and all of the options that may be involved.
The second form provides for a centeralized mechanism for configuring
what the options are to WebRun. This also reduces the amount of possible
local configuration error that a user may have. In the second form, WebRun
will parse an HTML file looking for its own special <META>
tags. WebRun will then execute each of those tags:
<META NAME="WebRun" CONTENT="webrun_options your.class.name your_options">
The second form must only have a single argument to the WebRun class. All actual arguments will then be processed from the WebRun meta tag.
Note: Some options are normally not shown to the user. These are specifically hidden to reduce support issues in thin-client environments. However, they can be useful as long as the person using them is available to support them. These advanced options are displayed when -H is given.
The options for WebRun are as follows: | |||
---|---|---|---|
parameter | description | ||
-h | Help - displays the usage information | ||
-R | Never put up a requester to get the user name and password | ||
-E | Do not put up a requester with the error codes | ||
-l URL | A URL to the directory where the class tree starts | ||
-j JarURL | A URL to a Jar file (you can use -j more than once | ||
-v | Verbose loading (stdout) | ||
-w | Verbose loading (window) | ||
Options only shown with '-H' | |||
-r | Put up a requester to get the user name and password | ||
-u user | User name for authorization | ||
-p password | Password for authorization | ||
-a authorization | The encoded authorization string | ||
-g user password | Generate an encoded authorization string | ||
-G | Put up a requester to get the user name and password and output the encoded authorization string | ||
WebRun was written by Michael Sinz. You can contact him at WebRun@Sinz.org.
WebRun needs at least a Java 1.1 environment in order to operate. The Apple Macintosh OS Runtime for Java, also known as MRJ provides the Java environment for the Macintosh OS. WebRun has been tested with the Apple MRJ 2.1 releases and specifically with the MRJ 2.1.4, which is the newest release available at this time. You can get the latest MRJ from Apple at http://devworld.apple.com/java/. You will also want to get the JBindery tool which is, unfortunately, only available in the MRJ SDK 2.1. It too is available at the Apple web site.
To install WebRun it is easiest to keep the binary file WebRun.zip and place that into the JBindery classpath settings. You can also extract the WebRun.class file from the zip file and add just that class to the classpath. (WebRun is all in a single class)
To then use WebRun you would put WebRun into the classname field in the JBindery. Then, for the optional parameters you would fill in the parameters as needed to run WebRun. (See above for details as to the options.) You would add the WebRun.zip file to the classpath in JBindery and that should be all that is needed for WebRun. If your application needs special properties added, you would also add those in the JBindery. One should normally not change the application settings, such as the min/max heap sizes. The Apple MRJ does most of its memory operations in the dynamic heap and thus does not need or want special min/max heap settings.
WebRun needs at least a Java 1.1 environment in order to operate. The Sun Java Runtime Environment for the 32-bit Microsoft Windows operating systems is a good place to start if you do not already have Java on your Windows machine.
Once you have the binary for WebRun (WebRun.zip) and Java installed on your machine you can then make shortcuts to run your various web based Java applications as follows:
Create a new shortcut by right-clicking into the desktop and selecting New->Shortcut. Enter into
the command line "jrew.exe -cp [path_to_webrun.zip]\webrun.zip WebRun [arguments_to_webrun]
"
See above for details as to the arguments to WebRun. If the jrew.exe command is not in your
command path then you need to enter the complete path to the jre.exe command. If you are having problems
or want STDOUT
available, you should replace jrew.exe with jre.exe in the
above example. The jrew.exe runs as a Windows application with no console while the jre.exe
runs as a Windows console application.
WebRun needs at least a Java 1.1 environment in order to operate. You can check this web page at Sun's Java site or with your operating system vendor for details as to where to get the Java JRE or JDK for your system.
Add the WebRun.zip file or the WebRun.class file to your classpath as needed by your environment. Due to the wide variety of operating environments on Unix systems I can not detail the steps needed to setup an icon or shortcut to run WebRun. The command line options and features are all detailed above and apply to all systems.
public InputStream getResourceAsStream(String name)
public URL getResource(String name)
It first checks the system for the resource. If it is not there it will then append the URL to the name and return that.
This API is really a poor API to use since it depends on having a URL that can point at the file. This depends on a number of things including authorization tokens and URL types being valid *and* that you can even make a URL to such a location; which is impossible with files that are inside of a JAR file. This is why getResourceAsStream is so much better.
public void run()
The thread is only created if AWT display of the load progress is asked for. It handles all of the display updating.
We are a window listener specifically so that we can handle the case of the user requesting to shut down the status window.
public void windowActivated(WindowEvent event)· windowDeactivated
public void windowDeactivated(WindowEvent event)· windowOpened
public void windowOpened(WindowEvent event)· windowClosing
public void windowClosing(WindowEvent event)· windowClosed
public void windowClosed(WindowEvent event)· windowIconified
public void windowIconified(WindowEvent event)· windowDeiconified
public void windowDeiconified(WindowEvent event)· actionPerformed
public void actionPerformed(ActionEvent e)
public static void runClass(ClassLoader loader, String className, String args[]) throws Throwable
public static void main(String args[]) throws Throwable