openjnlp-devel

[Openjnlp-devel] Arg...

[Christopher H. <he...@ez...>]

Well, as the old saying goes, when you're up to your armpits in alligators...

There's been a lot of alligator activity over the past month and a half, and 
I've been unable to put in any effort on the swamp itself (that is: OpenJNLP 
development).  However, over the next few days I hope to be able to put in 
some effort, and plan to look into the following things (in part to keep the 
local alligators well fed, thus keeping those pointy teeth away from my 
posterior):
	- A "--gui/-g" command line option which will pop up the GUI and open the 
specified file/URL.  F'rinstance:
		openjnlp --gui http://www.here.com/there.jnlp
Will pop-up the console, fetch the JNLP file, and then start the app.  The 
GUI will hang around after the launch for further JNLP fun.
	- When openjnlp is launched, look for one on the local machine with the same 
user (and under X, the same display), and have that one perform the requested 
tasks instead.

Exactly when I'll get these completed is not quite known, but this is the 
current plan.

						Chris

Re: [Openjnlp-devel] Arg...

[Kevin H. <ke...@na...>]

On Monday, March 25, 2002, at 09:25 , Christopher Heiny wrote:
[...]
> development).  However, over the next few days I hope to be able to put 
> in
> some effort, and plan to look into the following things (in part to 
> keep the

Yikes. I just did a whole bunch of changes to the launching process to 
support command-line operation. I needed stuff in openjnlp-lib which I 
just got working last night. I'll be committing the changes later today.

[...]
> 	- A "--gui/-g" command line option which will pop up the GUI and 
> open the
> specified file/URL.  F'rinstance:
> 		openjnlp --gui http://www.here.com/there.jnlp
> Will pop-up the console, fetch the JNLP file, and then start the app.  
> The
> GUI will hang around after the launch for further JNLP fun.

The main entry point for OpenJNLP (org.nanode.app.OpenJNLP) is the 
GUI-based application. I believe the GUI coming up should be the default 
behavior, maybe a -nogui option makes more sense.

> 	- When openjnlp is launched, look for one on the local machine 
> with the same
> user (and under X, the same display), and have that one perform the 
> requested
> tasks instead.

This sounds like some IPC between running instances of OpenJNLP, how 
would this work? On Mac OS it is possible to send 'odoc' events to tell 
a running app to open a document, but how would this be implemented in 
java on Windows and linux?

I will be following this message up with a separate message dedicated to 
command-line launching so we can all get a good handle on how we want 
OpenJNLP to work.

[Openjnlp-devel] OpenJNLP command-line launching

[Kevin H. <ke...@na...>]

I have implemented the launching properties thing inside the 
openjnlp-lib.jar as was previously discussed and added 
Gestalt.platformKey() to get a short string for each platform for 
creating properties like "launch.<key>.cmd=/usr/bin/java" where <key> is 
a key string returned by Gestalt.platformKey().

There needs to be a consensus on command-line operation, since we all 
have ideas on what we would like. I'll throw my world-view out to get 
the ball rolling on a discussion.

org.nanode.app.OpenJNLP     is the entry point for the 
platform-integrated application
org.nanode.jnlp.JNLPParser  is the entry point for JNLP 
parsing/caching/launching

When external launching occurs, org.nanode.launcher.Launcher will invoke 
(by default) org.nanode.jnlp.JNLPParser with appropriate switches.

I feel really good about the OpenJNLP-lib behavior, but I'm not quite 
sure about the application part. Until OpenJNLP gets to a point of 
handling JNLP files for web browsers I don't know if all the issues are 
clear.

With no further ado, here's my first at some actual documented 
behavior...


Proposed OpenJNLP-lib Behavior
------------------------------
org.nanode.jnlp.JNLPParser can be considered as the "OpenJNLP engine", 
allowing full control of the launching process. It will not do anything 
special other than perform whatever mechanical tasks specified. 
Arguments passed on command line after options will be treated as URLs 
to launch. If multiple URLs are specified and external launching is 
specified, each URL will be launched in a separate JVM. If internal 
launching is specified, all URLs will be launched in the current JVM.

Default launching behavior changes from launching internally to 
launching externally. This means org.nanode.launcher.Launcher be updated 
to reflect this. All "-extXXX" args have platform-specific defaults 
defined in "/lib/launcher.properties" inside the openjnlp.jar.

My idea of the current options are:

-version       show version of openjnlp-lib
-internal      launch within current JVM (external JVM launch is default 
behavior)

-extclasspath  <classpath to use when externally launching>
-extcmd        <command to invoke when externally launching>
-extmain       <main class name to invoke when externally launching>


Proposed OpenJNLP Application Behavior
--------------------------------------
org.nanode.app.OpenJNLP invokes the OpenJNLP application, which is 
defined as the user-friendly front-end to the OpenJNLP engine. It has 
two important jobs: to provide a good user experience (GUI or CLI) and 
to interface with the operating system.

The behavior of operating systems dictates that arguments on the command 
line must be treated as local files. If OpenJNLP is invoked with no 
arguments, it will assume the GUI should be invoked (interactive mode). 
If arguments are specified, it should run in "non-interactive" mode. The 
exact behavior of this mode is not quite clear in my mind at this stage. 
All launching is done as external launching.

An option can be set indicating the arguments should be treated as URLs 
instead. Another option will suppress the GUI.

My idea of options:

-version      show version of openjnlp
-gui          force GUI to come up regardless of arguments
-nogui        never bring up gui regardless of arguments
-urls         treat arguments as URLs instead of files

Re: [Openjnlp-devel] OpenJNLP command-line launching

[Kevin H. <ke...@na...>]

On Tuesday, March 26, 2002, at 04:01 , Kevin Herrboldt wrote:
[...]
> Proposed OpenJNLP-lib Behavior
> ------------------------------
> org.nanode.jnlp.JNLPParser can be considered as the "OpenJNLP engine", 
> allowing full control of

Everything laid out in the previous method was implemented and has been 
committed. org.nanode.launcher.Launcher has been updated and committed 
too.

For fun try "java -cp <whatever> org.nanode.jnlp.JNLPParser -help". Make 
sure you have SAX2 in your classpath or it won't run. Maybe that needs 
to be changed?

Here's the output for those who are interested:

Usage: org.nanode.jnlp.JNLPParser [-options] url [url...]

where options include:
     -help      print this help message
     -version   print product version
     -internal  launch url(s) in the current JVM

     -extcmd <cmd>
                command to use to invoke external launching
     -extclasspath <jar files separated by :>
                jars to add to classpath for external launching
     -extmain <classname>
                classname to call for external launching