Class WebRun

java.lang.Object
   |
   +----java.lang.ClassLoader
           |
           +----WebRun

public class WebRun
extends ClassLoader
implements Runnable, WindowListener, ActionListener

WebRun 2.7

Copyright 1998-2001 Michael Sinz.  All rights reserved.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.  The source code must always be available via any distribution mechanism by which the binary is made available.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to:
Free Software Foundation, Inc. 59 Temple Place Suite 330 Boston, MA 02111-1307 USA.

WebRun 2.7

A simple Java Application Starter that can load jars and class files from URLs, including password protected URLs. WebRun offers the benefits of Java without the overhead or bugs of web browsers.

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.

You can try an example here.

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:
parameterdescription
-hHelp - displays the usage information
-RNever put up a requester to get the user name and password
-EDo not put up a requester with the error codes
-l URLA URL to the directory where the class tree starts
-j JarURLA URL to a Jar file (you can use -j more than once
-vVerbose loading (stdout)
-wVerbose loading (window)
Options only shown with '-H'
-rPut up a requester to get the user name and password
-u userUser name for authorization
-p passwordPassword for authorization
-a authorizationThe encoded authorization string
-g user passwordGenerate an encoded authorization string
-GPut 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.

Using WebRun with Apple Macintosh computers

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.

Using WebRun with Microsoft Windows 95/98/NT/2000

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.

Using WebRun with Unix Systems such as Solaris, Linux, FreeBSD, AIX, etc.

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.


Method Index

· actionPerformed(ActionEvent)
The action listener for our password entry window.
· getResource(String)
Get the resource as a URL.  This can only get resources that are not in a JAR file since there is no URL that can point into a JAR file.
· getResourceAsStream(String)
Get an InputStream on a given resource.  Will return null if no resource with this name is found.  This can get resources from the jar files (and will check those first, after the standard system resources) and from the URL
· main(String[])
The main entry point for the remote application launcher.
· run()
In order to do the AWT based form of the loading display we need to separate the display from the class loading so that they don't interact with each other.  We try our best to keep the amount of code that has to run in synchronization blocks to an absolute minimum and keep as much of the information "local" to this thread.
· runClass(ClassLoader, String, String[])
Run the given class's main() method with the arguments given after loading it from the class loader.
· windowActivated(WindowEvent)
· windowClosed(WindowEvent)
· windowClosing(WindowEvent)
· windowDeactivated(WindowEvent)
· windowDeiconified(WindowEvent)
· windowIconified(WindowEvent)
· windowOpened(WindowEvent)

Methods

· getResourceAsStream
 public InputStream getResourceAsStream(String name)
Get an InputStream on a given resource.  Will return null if no resource with this name is found.  This can get resources from the jar files (and will check those first, after the standard system resources) and from the URL

Parameters:
name - the name of the resource, to be used as is.
Returns:
an InputStream on the resource, or null if not found.
Overrides:
getResourceAsStream in class ClassLoader
· getResource
 public URL getResource(String name)
Get the resource as a URL.  This can only get resources that are not in a JAR file since there is no URL that can point into a JAR file.

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.

Parameters:
name - The file name for the resource.
Returns:
a URL that points to the resource.  This may, however, not actually work since the resource may be within a JAR file or behind security in a web server and the JDK supplied URL handlers do not support these types of operations.
Overrides:
getResource in class ClassLoader
See Also:
getResourceAsStream
· run
 public void run()
In order to do the AWT based form of the loading display we need to separate the display from the class loading so that they don't interact with each other.  We try our best to keep the amount of code that has to run in synchronization blocks to an absolute minimum and keep as much of the information "local" to this thread.

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.

· windowActivated
 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)
The action listener for our password entry window.

· runClass
 public static void runClass(ClassLoader loader,
                             String className,
                             String args[]) throws Throwable
Run the given class's main() method with the arguments given after loading it from the class loader.

Parameters:
loader - The class loader to use.
className - The fully qualified name of the class to run.
args - The arguments that will be passed to main() in the class.
Throws: Throwable
Anything that gets thrown by this will just be passed along.  This catches nothing.
· main
 public static void main(String args[]) throws Throwable
The main entry point for the remote application launcher.

Throws: Throwable
This will throw anything that could be thrown by the main() method of the class that got loaded along with possible exceptions for not finding the class or other class loading errors.

There have been  Counter  visitors to this page.