openjnlp-devel Mailing List for OpenJNLP (Page 4)
Brought to you by:
kherr
Menu
▾
▴
openjnlp-devel — Technical discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
(7) |
Mar
(6) |
Apr
(9) |
May
(29) |
Jun
(13) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2003 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mario C. <mar...@po...> - 2002-05-09 17:02:21
|
Kevin, I noticed your modifications to handle lazy jars this morning. I must admit that was fast work. And it (mostly) works, too! : ) The only problem I saw was intermitent but I managed to pinpoint its source: non-class resources loaded from lazy jars. I think you need to make modifications to FileCacheClassLoader.findResource() to wait for lazy jars like you did in findClass(). In my application, the problem showed up in various different ways that can all be traced back to a missing non-class resource: icons missing, property files missing, JAXP meta-inf/services/javax.xml.parsers.SAXParserFactory file missing (that one threw me off because it resulted in a ClassNotFoundException on the fallback value, so I initially thought your implementation was broken)... All of these problems are intermitent, because they depend on how fast the background thread can load the required jars. I hope this helps, and thanks again for your great work... Mario |
|
From: Mario C. <mar...@po...> - 2002-05-08 21:42:09
|
Kevin, First of all, the specification states that "a JNLP Client is always allowed to eagerly download all resources if it chooses". I think that as a default, you could use that instead of not doing anything with lazily downloadable resources. At least things would work, and comply to the spec too. Second, I reread this part of the specification and it still seems to me that my patch is a valid implementation as per the spec. I agree with you that it is desirable to cache the lazily downloaded resources (for performance but especially for offline launching), but I don't think you are required to. My solution was inspired by a footnote in a previous version of the spec that said "Lazy download is a standard feature of the Java 2 Platform's class loading mechanism." This pointed directly to the URLClassLoader, as far as I can tell. However, this footnote disappeared from later revisions, so maybe they did imply that caching was if not mandated, at least strongly suggested, considering the offline scenarios. In my opinion, lazy resources should be specified as remote URLs initially, and these remote references be progressively replaced with local URLs as the resources are downloaded in the background. However, URLClassLoader does not support such replacements of jars. On the other hand, using the remote URL on the first execution, and the local URL on subsequent executions, achieves the same results. Just my current thoughts on the subject, open to discussion... : ) Mario > > I tried running a JNLP app that used lazy loading of some jars, and it > > simply didn't work because of ClassNotFoundExceptions. Going through > > the code, I noticed that nothing is done about lazy jars. My > > understanding of the spec. is that these jars should always be loaded > > over the network, like applet jars. Is so, the correct way to > > implement it would be to add the remote (http:) URLs > > You are correct, OpenJNLP does not yet support lazy jars. Unfortunately, > your interpretation of loading lazy jars doesn't seem to agree with the > specification. Lazy jars still are cached locally, but are not retrieved > until needed. The pertinent part of the JNLP specification is Section > 4.4, "Parts and Lazy Downloads". For this reason I don't think I can use > your suggested changes (as good as they are) but I will use your work as > motivation to get lazy jars implemented. > > [...] |
|
From: Kevin H. <ke...@na...> - 2002-05-08 20:35:59
|
I've just committed code to cvs that gives OpenJNLP the ability to launch applets that are described by JNLP files using <applet-desc>. Everything seems to work, including audio. I don't know where any JNLP applets exist in the wild, though, so I don't know how important this is. Yet, anyway. |
|
From: Kevin H. <ke...@na...> - 2002-05-08 20:15:16
|
On Wednesday, May 8, 2002, at 02:34 , Mario Cormier wrote: > I tried running a JNLP app that used lazy loading of some jars, and it=20= > simply didn't work because of ClassNotFoundExceptions.=A0 Going = through=20 > the code, I noticed that nothing is done about lazy jars.=A0 My=20 > understanding of the spec. is that these jars should always be loaded=20= > over the network, like applet jars.=A0 Is so, the correct way to=20 > implement it would be to add the remote (http:) URLs You are correct, OpenJNLP does not yet support lazy jars. Unfortunately,=20= your interpretation of loading lazy jars doesn't seem to agree with the=20= specification. Lazy jars still are cached locally, but are not retrieved=20= until needed. The pertinent part of the JNLP specification is Section=20 4.4, "Parts and Lazy Downloads". For this reason I don't think I can use=20= your suggested changes (as good as they are) but I will use your work as=20= motivation to get lazy jars implemented. [...] > Also note that on the Windows 2000 system I'm using to test this, the=20= > FileCache.toSafeURL() method breaks the local file: URLs, even though=20= > it seems like the correct thing to do. Yeah, what I've discovered is that the "file" URL protocol handler from=20= Sun is completely broken. You can't use correct URL encoding as per RFC=20= 2396 for file paths. I had to back out the FileCache.toSafeURL() calls.=20= I ran into some serious problems with that and the way RMI works.=20 Something has to be done about spaces in names in the cache. Blah. |
|
From: Mario C. <mar...@po...> - 2002-05-08 19:31:32
|
I tried running a JNLP app that used lazy loading of some jars, and it =
simply didn't work because of ClassNotFoundExceptions. Going through =
the code, I noticed that nothing is done about lazy jars. My =
understanding of the spec. is that these jars should always be loaded =
over the network, like applet jars. Is so, the correct way to implement =
it would be to add the remote (http:) URLs of the jars when constructing =
the class loader for the application (eager jars use local file: URLs). =
I went ahead and made the required changes in FileCacheEntry, and =
included them below. Maybe it will be useful to some people, maybe it =
will be included in the CVS tree, or maybe someone will set me straight =
on this issue.
Also note that on the Windows 2000 system I'm using to test this, the =
FileCache.toSafeURL() method breaks the local file: URLs, even though it =
seems like the correct thing to do.
Hope this will be useful to someone,
Mario
Index: FileCacheEntry.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: =
/cvsroot/openjnlp/devel/src/org/nanode/launcher/cache/FileCacheEntry.java=
,v
retrieving revision 1.12
diff -w -r1.12 FileCacheEntry.java
157,159c157
< ArrayList eager =3D new ArrayList();
< File jarFile;
< URL jarURL;
---
> ArrayList urlList =3D new ArrayList();
162,164c160,166
< for (Enumeration enum =3D entryDescriptor.getResources().eagerJars(); =
enum.hasMoreElements();) {
< jarURL =3D ((Reference) enum.nextElement()).getURL();
< jarFile =3D new File(getResourceDir(), FileCache.cacheName(jarURL));
---
> for (Enumeration enum =3D entryDescriptor.getResources().jars(); =
enum.hasMoreElements();) {
> Reference jarReference =3D (Reference) enum.nextElement ();
> URL jarURL =3D jarReference.getURL ();
> if (jarReference.isLazy ()) {
> urlList.add (jarURL);
> } else { // Eager
> File jarFile =3D new File(getResourceDir(), =
FileCache.cacheName(jarURL));
167c169,170
< eager.add(FileCache.toSafeURL(jarFile));
---
> // TODO: This safeURL thing doesn't work under Windows 2000...
> urlList.add(jarFile.toURL () /* MC: WAS: =
FileCache.toSafeURL(jarFile)*/);
171a175
> }
173,174c177,178
< URL[] classpath =3D new URL[eager.size()];
< classpath =3D (URL[]) eager.toArray((Object[]) classpath);
---
> URL[] classpath =3D new URL[urlList.size()];
> classpath =3D (URL[]) urlList.toArray((Object[]) classpath);
|
|
From: Christopher H. <he...@ez...> - 2002-04-27 08:20:49
|
Well, after more than a tad of thrashing and rework (mainly due to my own paranoia - I'm trying to make Elvis reasonably secure against attacks and hangs) Elvis is alive! Aside from the rename (dropped the J, which got added in a moment of low lemming resistance - thanks for the nudge Kevin!), Elvis is now able to determine if he is or is not the only Elvis implementing a given program, and if he is not, defer to the more senior Elvis. I haven't gotten as far as having Elvis do actually anything yet, but it's going to be a cool, damp weekend, with two Nascar races on the net broadcast, so I suspect a good bit of work will get done. At this point, I'm going to babble incoherently about some security related details. If you have the inclination to read further, I'd appreciate feedback on these points. As I mentioned above, I've been a bit paranoid about the connection setup. Elvis talks to himself in "one liners" - single line messages consisting of a sequence of header tokens (three header tokens, identifying it as an Elvis message, for a given program, and a key identifying the specific incarnation of Elvis who is (supposedly) the Real Elvis at this time), an action token indicating what it is we want Elvis to do, and an optional data token, which can be any arbitrary plain text string (not including end-of-line). The response is a similar "one liner", with a status token substituted for the action token. In both cases all three header tokens must be correct for Elvis to accept the communication. The whole point of this is to help prevent spoofing attacks, where one user attempts to get another user's Elvis to do something. At the moment, though, this whole effort is short circuited because the key is stored in world readable plain text in a well known file in a well known directory. Once that is secured (by making it readable only be the proper user), the whole structure hardens up nicely. For additional paranoia, the Elvis port is chosen semi-randomly, by adding a random offset to a base port number supplied by the client.. This should make port guessing by an attacker difficult, except that the port number is stored in the same vulnerable directory mentioned above (and can be fixed in the same way). Right now, if Elvis receives a connection attempt from a machine other than the local host, he decides that he's under attack and exits immediately. This could be inconvenient in a production environment, and needs some more thought. Since Java is inherently resistant to buffer overflow attacks, that isn't a big concern. It might be more appropriate to simply have Elvis log such attempts and discard the connections without further action. The goal is to close any doors through which an attacker could get an Elvis implementation to do something. For OpenJNLP, this could include worm programs, trojans, or access to otherwise secure data. Chris |
|
From: Christopher H. <he...@ez...> - 2002-04-23 20:12:42
|
OK, it's been a bit since I last checked in. I've been working on the
"JElvis" class (there is only one Elvis, after all), which can be used to
help ensure that only a single OpenJNLP is active at a time. Since this is a
facility we'll want to use in our own projects, I'm trying to make it into a
relatively general library class. This is adding a bit of time to the design
phase and initial implementation.
Additionally, there have been a number of distractions in the non-OpenJNLP
world that have been distracting me from this, including a two week code
review at work, and a successful crack on my home network (my fault - left an
unsafe connection open too long ("it won't happen to me") and the whole place
got rootkit'ed).
Anyway, work is progressing, and in the next couple of weeks I hope to have
JElvis 0.1 ready for test integration.
Chris
|
|
From: Markus K. <Mar...@mp...> - 2002-04-11 11:27:39
|
I come back to the question of sharing op/se under an improved scheme. The question is about a year old. The background: Optional packages/standard extensions are installed by copying jar-files in JRE/lib/ext. Using JNLP, this is the only way, for Applets there exist more options. copying files to lib/ext is the last thing you want to do. I want to propose (in the JSR) to extend the JNLP specification to include a new tag <extensionjar>, which will set the JVM to tread the specified class as if loaded from lib/ext. Find details attached. I would like to discuss the following: Given an element <extensionjar>, would it be easy to share extensions? I believe yes. The situation would become the following: --------------------------- <jnlp> ... <resources> ... <jar href="xyz". <extensionjar="http://foo/bar__Vwhatever.jar"> ... ---------------------------- The advantage of using the internet as the namespace is that it resolves all the version/naming conflicts of lib/ext (the DLL-hell for Java). I see a problem in the mix of certificates used. The jar files will have different certificates. Currently, all jar within a <jnlp> description has to be signed with the same certificate (if signed at all). In order to share a op/se, there are number of options: - write a <jnlp> wrapper, - release the restrictions. I don't know what is better. Please tell me your thoughts. -Markus |
|
From: Kevin H. <ke...@na...> - 2002-04-10 22:05:32
|
On Wednesday, April 10, 2002, at 10:46 , Scott Kovatch wrote: > Take a look at the developer info on JNLP and Web Start from Sun. You > can download a developer's pack that has a servlet that can process > jardiff requests. > > http://java.sun.com/products/javawebstart/developers.html > > I'm not sure if OpenJNLP supports them, however. I believe you are responsible for creating the jardiff, and you need the servlet in order to deliver the jardiff to the JNLP client. I'm not sure if the effort is worthwhile, though. Since the JNLP client caches the jar on the remote machine, downloading is minimal (or at least infrequent) from an end-user perspective. That being said, OpenJNLP does not support jardiff yet but it will eventually. Currently jardiff is a low-priority feature in OpenJNLP, but only because no-one has been asking for it. |
|
From: Scott K. <sko...@ap...> - 2002-04-10 17:46:30
|
Take a look at the developer info on JNLP and Web Start from Sun. You can download a developer's pack that has a servlet that can process jardiff requests. http://java.sun.com/products/javawebstart/developers.html I'm not sure if OpenJNLP supports them, however. Scott On Wednesday, April 10, 2002, at 04:35 PM, Joan Puig Giner wrote > Since I am new to this JWS technology I have questions regarding both > ends. > First of all, how do I set up my web server (Apache) to be able to > generate > those JARDiff. I realize that this is not the best place to post this > question but I just thought you may know how to get me started in the > right > direction. The second question is if OpenJNLP will be able to use them? > _____________________ Scott Kovatch Java Runtime Classes Apple Computer Cleveland Hts, OH sko...@ap... |
|
From: Joan P. G. <gt...@pr...> - 2002-04-10 17:36:16
|
Markus, I was reading the JNLP specs (http://java.sun.com/products/javawebstart/download-spec.html) and in section 6.3.1 it talks about making incremental updates using JARDiff files. I think this is a 2 end challenge: the server must be able to provide that file and the client must be able to understand this type of file. Since I am new to this JWS technology I have questions regarding both ends. First of all, how do I set up my web server (Apache) to be able to generate those JARDiff. I realize that this is not the best place to post this question but I just thought you may know how to get me started in the right direction. The second question is if OpenJNLP will be able to use them? Thanks Joan -----Original Message----- From: Markus Kramer [mailto:Mar...@mp...] Sent: Wednesday, April 10, 2002 12:58 AM To: Joan Puig Giner Cc: ope...@li... Subject: Re: [Openjnlp-devel] OpenJNLP features Joan, JWS and OpenJNLP both run on the client and feed the Java Virtual Machine. On the server, you need to set up JNLP-descriptions, which point to any number of jar files. If you put newer versions of the jars on your web-server, they will be looked up and downloaded. This behaviour is specified in the JNLP-protocol. From reading your mail, I get the impression that with "individual file" you mean a single .class file. You cannot send single .class files to the client, you have to put them in a jar. At my institute, we also develop some rather big applications, and we found updating/versioning very easy to to with JNLP. We currently put all bytecode into a single jar file (for each app). This leads to an update, which will download a lot of unchanged code, but its the easiest to organize. I guess this is what your question is about. When we want to cut our application into smaller pieces/components, I cannot see where DeployDirector is of help. The ability to specify the download-directory seems to involve more than the JNLP-protocol allowas, so the DeployDirector must do something extra. To be onest, I cannot see the benefit of DeployDirector. After going through the 'Walktrough' of DeployDirector, I get the impression that it is a Graphical interface to the JNLP-descriptions you can write in any editor (they are XML). Please correct me if I understood you wrong. -Markus Joan Puig Giner wrote: > We are planning to develop an application that is going to be rather big and > it will be evolving quick. We have been looking at deployment products and > we have found JWS that makes you download the entire .JAR file and > DeployDirector that does everything we need but we can't afford it. > > (assuming it will be able to tell if a file is up to date or not) my > question is, does OpenJNLP support individual file download ? if not, any > plans to implement that within 6 months? > > Thanks > Joan > > _______________________________________________ > Openjnlp-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjnlp-devel |
|
From: Markus K. <Mar...@mp...> - 2002-04-10 07:58:33
|
Joan, JWS and OpenJNLP both run on the client and feed the Java Virtual Machine. On the server, you need to set up JNLP-descriptions, which point to any number of jar files. If you put newer versions of the jars on your web-server, they will be looked up and downloaded. This behaviour is specified in the JNLP-protocol. From reading your mail, I get the impression that with "individual file" you mean a single .class file. You cannot send single .class files to the client, you have to put them in a jar. At my institute, we also develop some rather big applications, and we found updating/versioning very easy to to with JNLP. We currently put all bytecode into a single jar file (for each app). This leads to an update, which will download a lot of unchanged code, but its the easiest to organize. I guess this is what your question is about. When we want to cut our application into smaller pieces/components, I cannot see where DeployDirector is of help. The ability to specify the download-directory seems to involve more than the JNLP-protocol allowas, so the DeployDirector must do something extra. To be onest, I cannot see the benefit of DeployDirector. After going through the 'Walktrough' of DeployDirector, I get the impression that it is a Graphical interface to the JNLP-descriptions you can write in any editor (they are XML). Please correct me if I understood you wrong. -Markus Joan Puig Giner wrote: > We are planning to develop an application that is going to be rather big and > it will be evolving quick. We have been looking at deployment products and > we have found JWS that makes you download the entire .JAR file and > DeployDirector that does everything we need but we can't afford it. > > (assuming it will be able to tell if a file is up to date or not) my > question is, does OpenJNLP support individual file download ? if not, any > plans to implement that within 6 months? > > Thanks > Joan > > _______________________________________________ > Openjnlp-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjnlp-devel |
|
From: Joan P. G. <gt...@pr...> - 2002-04-09 20:33:41
|
We are planning to develop an application that is going to be rather big and it will be evolving quick. We have been looking at deployment products and we have found JWS that makes you download the entire .JAR file and DeployDirector that does everything we need but we can't afford it. (assuming it will be able to tell if a file is up to date or not) my question is, does OpenJNLP support individual file download ? if not, any plans to implement that within 6 months? Thanks Joan |
|
From: Kevin H. <ke...@na...> - 2002-04-05 03:23:30
|
The Launcher has been overhauled once more...
The cache is now stored in "~/Library/Caches/OpenJNLP" on Mac OS X,
still in "~/.jnlp/cache" on all other platforms. On Mac OS X the cache
will be automatically moved if it's found in the old location.
Instead of creating a complex classpath when invoking the external
launcher, OpenJNLP now uses the "java.ext.dirs" property to point to the
directory holding all of the launcher jars. This is now in the
"launcher" directory within the cache. Every time external launching is
invoked the launcher checks to see if the "launcher" dir needs updating.
If so, it copies all necessary jars into the location. After files are
copied a "version.txt" file is written with the launcher version. This
file is used to determine when to copy new files.
The launcher.properties file has been changed to support the new
behavior:
"launcher.files" added, lists all of the files that
need to be copied
"launcher.<platform>classdir" added, directory where files
should be found
"launcher.<platform>.classpath" removed
OpenJNLP has also been upgraded to SAX 2.0.1 and NanoXML 2.2. The jar
names are all different.
|
|
From: Kevin H. <ke...@na...> - 2002-03-27 21:12:55
|
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
|
|
From: Kevin H. <ke...@na...> - 2002-03-27 21:08:35
|
On Tuesday, March 26, 2002, at 03:39 , Christopher Heiny wrote: [...] >> 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 think the Jext text editor has a reasonable approach. You do it > with a > socket. (see http://jext.sourceforge.org for Jext info; the method I'm This is a good idea, the socket thing would enable a single OpenJNLP in GUI mode to be the arbiter for launching, which really makes sense now with the console. |
|
From: Kevin H. <ke...@na...> - 2002-03-26 22:00:52
|
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 |
|
From: Christopher H. <he...@ez...> - 2002-03-26 21:43:29
|
On Tuesday 26 March 2002 11:21 am, you wrote: > 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. OK, I'll hold off starting anything till you get that done. >> - 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. Well, right now the default is a GUI if no command line .jnlps are found; and no GUI if there are .jnlp files on the command line. This works nicely with browser based JNLP launching - casual users can just say "openjnlp %f" (or whatever your browser wants) in their mime types, and the browsed app launches 'by magic' with OpenJNLP remaining behind the curtain. By extension, I figured more advanced users who want both to launch an app and the GUI would explicitly request that by saying "openjnlp --gui <JNLP>". This has the additional benefit of not changing the current behavior of OpenJNLP. > >> - 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 think the Jext text editor has a reasonable approach. You do it with a socket. (see http://jext.sourceforge.org for Jext info; the method I'm looking at is org.jext.JextFrame.loadInSingleJVMInstance(), see attached file). This method is invoked at tool start up, and (in a very simplified overview) executes the following code: // authorization key is a cookie left in a well known place // by another instance of Jext if ( authorizationKey.exists() ) { // there might be another instance open a socket to localhost try to talk to the instance on the other end if ( success ) { tell the other instance what we want it to do exit } else { // he's not there delete the key } } create our own key stash the key in the well known place create an appropriate socket listener Using a Socket is nice, since Sockets are platform independent and have been in just about every JRE since the dawn of time. I'm pretty sure they're in J2ME, which helps if we want to make OpenJNLP embeddable. I'd probably do some tinkering with it, both to make it a little more secure, and to turn it into a Bean (or start it along that path) so that it can be readily dropped into other apps. Chris |
|
From: Kevin H. <ke...@na...> - 2002-03-26 19:21:30
|
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. |
|
From: Christopher H. <he...@ez...> - 2002-03-26 03:25:07
|
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 |
|
From: scott p. <sco...@va...> - 2002-02-25 14:58:16
|
Thanks Kevin and Christopher for responding. I will take a much closer look
now.
Scott
-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Kevin
Herrboldt
Sent: Sunday, February 24, 2002 11:39 PM
To: ope...@li...
Subject: Re: [Openjnlp-devel] Questions about OpenJNLP
On Sunday, February 24, 2002, at 10:16 , Christopher Heiny wrote:
[...]
> 1) As far as I can tell, it should - if you pass it a jnlp file as an
> argument, it opens that file without opening the GUI.
All of the GUI-related code is in openjnlp-app.jar. If passing the URL
as an argument doesn't work there, you can invoke OpenJNLP in non-GUI
mode by passing the URL(s) as arguments using
"org.nanode.jnlp.JNLPParser" as the main class.
> 2) Not that I know of, but it's a cool idea. After 35 seconds
> thought, I
> can't think of a reason why it wouldn't be fairly easy for most apps
> (if the
Killing off running apps is an idea I've had for a while, although it's
been rather low priority. Since the OpenJNLP launcher tracks all
launched apps via the corresponding java.lang.Process object it should
be possible to stop a running app. It's very abrupt and is not a good
way to stop stuff but could be done.
> 3) Wellllll Kevin Herr is the most consistent developer. I've been
> working
OpenJNLP is pretty far along, IMHO. It's quite functional as a JNLP
client, supporting execution of the majority of JNLP apps written. Some
plans for OpenJNLP are (in no particular order):
Updated 1.1 version
Required JNLP services
Optional JNLP services
Applet launching
Operating System integration (".jnlp" file mapping, allowing links in
browsers to launch)
Cache management
Version-based updating
Security
The launching stuff was a major feature. Launching is pretty decent now
although it needs improvement. Security is the next "big thing" that
will take a major amount of effort.
_______________________________________________
Openjnlp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openjnlp-devel
|
|
From: Kevin H. <ke...@na...> - 2002-02-25 04:39:18
|
On Sunday, February 24, 2002, at 10:16 , Christopher Heiny wrote:
[...]
> 1) As far as I can tell, it should - if you pass it a jnlp file as an
> argument, it opens that file without opening the GUI.
All of the GUI-related code is in openjnlp-app.jar. If passing the URL
as an argument doesn't work there, you can invoke OpenJNLP in non-GUI
mode by passing the URL(s) as arguments using
"org.nanode.jnlp.JNLPParser" as the main class.
> 2) Not that I know of, but it's a cool idea. After 35 seconds
> thought, I
> can't think of a reason why it wouldn't be fairly easy for most apps
> (if the
Killing off running apps is an idea I've had for a while, although it's
been rather low priority. Since the OpenJNLP launcher tracks all
launched apps via the corresponding java.lang.Process object it should
be possible to stop a running app. It's very abrupt and is not a good
way to stop stuff but could be done.
> 3) Wellllll Kevin Herr is the most consistent developer. I've been
> working
OpenJNLP is pretty far along, IMHO. It's quite functional as a JNLP
client, supporting execution of the majority of JNLP apps written. Some
plans for OpenJNLP are (in no particular order):
Updated 1.1 version
Required JNLP services
Optional JNLP services
Applet launching
Operating System integration (".jnlp" file mapping, allowing links in
browsers to launch)
Cache management
Version-based updating
Security
The launching stuff was a major feature. Launching is pretty decent now
although it needs improvement. Security is the next "big thing" that
will take a major amount of effort.
|
|
From: Christopher H. <he...@ez...> - 2002-02-25 04:16:41
|
On Wednesday 20 February 2002 10:11, scott pennell wrote: > Hello, > > 1. Does OpenJNLP support the "execution" of JNLP files from a GUI-less > machine (no Xserver for instance)? > 2. Is there a way to stop a running application vis OpenJNLP once it has > been started? > 3. How far along is the development process? > > Thanks! > > I have a middle-ware JINI application (set of services) I need to have > installed. JWS has some drawbacks in that it requires a GUI environment and > also has no way of stopping an application started with it (except using > kill -9)! Other than that, it is perfect for my needs. I hope this open > source project provides a good alternative. Thanks. > 1) As far as I can tell, it should - if you pass it a jnlp file as an argument, it opens that file without opening the GUI. 2) Not that I know of, but it's a cool idea. After 35 seconds thought, I can't think of a reason why it wouldn't be fairly easy for most apps (if the app starts spawning other JVMs and/or processes, that could be a problem); that doesn't mean it actually is easy. 3) Wellllll Kevin Herr is the most consistent developer. I've been working on it in fits and starts over the past few weeks, and have started folding our local work back into the main code base. Kevin has been thinking more strategically than I have (I concentrate mainly on "what do we need right now here at my company"), and is probably the better person to answer where OpenJNLP is going. Chris |
|
From: scott p. <sco...@va...> - 2002-02-20 18:11:42
|
Hello, 1. Does OpenJNLP support the "execution" of JNLP files from a GUI-less machine (no Xserver for instance)? 2. Is there a way to stop a running application vis OpenJNLP once it has been started? 3. How far along is the development process? Thanks! I have a middle-ware JINI application (set of services) I need to have installed. JWS has some drawbacks in that it requires a GUI environment and also has no way of stopping an application started with it (except using kill -9)! Other than that, it is perfect for my needs. I hope this open source project provides a good alternative. Thanks. ---------------------- Scott Pennell Valaran Corporation 609-945-7260 http://www.valaran.com "This communication may include the proprietary and confidential information of Valaran Corporation. If you believe you have received this communication in error, please delete all copies and notify the sender by replying to this e-mail." |
|
From: Christopher H. <he...@ez...> - 2002-02-19 08:09:45
|
On Monday 18 February 2002 11:53, Kevin Herrboldt wrote:
> On Sunday, February 17, 2002, at 10:27 , Christopher Heiny wrote:
> > We're bumping into some problems with the location of the
> > lib/openjnlp.properties files. Since we can't control what directory
> > the
> > user will invoke OpenJNLP from, or where they will install it, this is
> > causing problems (especially in Windows).
>
> I realized almost since release of the newer launcher that it was
> tragically flawed in that regard. Relying on a filesystem structure for
> operation is so wrong.
>
> > Do you see any difficulty with converting the info in
> > openjnlp.properties
> > into a resource bundle and putting that in the .jar? The idea would be
> > to
> > name resources like this
> > launcher.<resource>.<os>
>
> I've been kicking around the idea of doing this. Essentially my thoughts
> are along the lines of putting "/lib/launcher.properties" inside the
> openjnlp-lib.jar and then merging all of the OS-specific launcher
> properties into one file. I was thinking more of a naming convention of
> "launcher.<os>.<resource>" which seems more consistent with properties
> file conventions, but that's a minor detail. The synthesis of the
> correct platform could easily be added to org.nanode.launcher.Gestalt,
> since it already figures out the OS type.
"launcher.<os>.<resource>" makes more sense.
> To get around the user-editable issue, the launcher could look in like
> "${user.home}/.jnlp/openjnlp.properties" for launcher property
> overrides, falling back to the "/lib/launcher.properties" resource if
> necessary.
Sounds sensible. For right now I propose using a simple resource class from
another project we're working one. This class that supports chained
resource bundles, where trailing links act as successive, sequential defaults
for the head link (this may get expanded to a tree impl shortly). This will
enable defaulting as described above, although I probably won't get around to
actually loading the user properties file for a bit.
Now for the hairier issues....
> None of this solves the classpath issue for launching call. Figuring out
> the correct classpath needs to be done in some fashion better than
> hardcoding relative paths in a classpath property. I used to have logic
> in the launcher that stripped the classpath values out of the
> "java.class.path" property, which might work.
On the other hand, it might be possible to do some gyrations to derive a URL
for the current openjnlp.jar file - then presumably the other jars could be
constructed fairly simply from that URL. This may be a somewhat twisted
variant of option (3) in the long run. However, I think it would have the
added benefit of working when launched from JWS (this idea needs a bit more
investigation).
The idea of having a jar based OpenJNLP installer is a great one. One of
the main reasons we are going with JNLP here is to avoid having to figure out
on a user by user basis which subset of the app palette is needed, and then
install it. This is especially true of our Windows users, since they tend to
have less of the "well, I'll just figure it out" attitude than our
Linux/Solaris folks. I think I may leave it to someone else to tackle the
implementation, though.
KDE/Gnome integration would sure help encourage people to choose OpenJNLP
over JavaWS. Once again, I'm not going to sign up for implementing that just
yet, though I believe it would be a relatively simple task.
Chris
|
