openjnlp-devel Mailing List for OpenJNLP (Page 3)
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: Kevin H. <ke...@na...> - 2002-06-03 02:13:42
|
On Wednesday, May 29, 2002, at 12:10 , Christopher Heiny wrote: > Cool! [...] > At any rate, when I'm done working these through, I'll let you know what > modules actually have worthwhile changes in them. Since you are > presumably > doing more intensive work on the launcher and related classes, I'll try > to > keep things simple to avoid merge problems. You should definately commit any fixes or improvements you've done. I'm not doing anything much more with the launcher, it's pretty stable right now. I know it seems like I don't check in often, but I do actually subscribe to a philosophy of frequent check-ins. If you've got fixes in you should feel free to commit them. The only thing that's important is to make sure the code checked in compiles, and ideally actually still works. |
|
From: Christopher H. <he...@ez...> - 2002-05-29 05:11:12
|
Cool! I've downloaded and started working with it. I've found some niggling little errors (mostly references to null pointers), and made a couple of changes for improved diagnostics. That java.lang.VerifyError problem turned out to be a null pointer - although why the VM didn't toss a NullPointerException for it, I don't know. At any rate, when I'm done working these through, I'll let you know what modules actually have worthwhile changes in them. Since you are presumably doing more intensive work on the launcher and related classes, I'll try to keep things simple to avoid merge problems. Chris |
|
From: Kevin H. <ke...@na...> - 2002-05-27 02:02:55
|
I meant to post this info a few days ago... OpenJNLP has been tweaked with a much improved self-updating launcher. Here's a breakdown of what's new: FileCachedResource is no longer an inner class, and can be used directly without anything else. The constructor simply needs a Reference and a directory (File object) to store the resource in. You can also supply a separate directory for the place to expand native libs. If the lib dir is null no expansion will be done. CachedResource.update() is now public and can be called at any time to update the resource in the cache. The external launcher now only checks to update itself once. The check for an update is done from Launcher.launchExternal() which still always calls Launcher.updateLauncher(), but updateLauncher() will only do the update once. updateLauncher() tries to update the launcher jars from the installed application itself, based on where the jars are supposed to be (from the launcher.properties file). If that location can't be accessed then updateLauncher() will use the launcher network home for the jars. This is set in launcher.properties to <http://openjnlp.nanode.org/launcher>. I've got nearly-current files out there so network updating is functional. The updating is done using the new FileCachedResource for each launcher jar. There were a number of problems I found in the original CachedResource.update() code which have been fixed. In addition to this FileCachedResource.update() will also use File.setLastModified() to set the last modified date of the cache file to whatever the date on the source (server side) is. I also had to tweak CachedResource.getRemoteLastModified() for special checking of file URLs because Sun's "file:" URLStreamHandler is poorly implemented. Finally, the build process now combines all of the xml-related jars into a single "openjnlp-extra.jar". The purpose of this is to avoid weird version naming issues that might arise (such as with NanoXML, for example). The idea behind "openjnlp-extra.jar" is it will contain any third-party code that the launcher needs. The ant build uses the <jlink> task to combine jars, which is part of the ant optional tasks jar, so make sure and have those installed if building with ant. |
|
From: Kevin H. <ke...@na...> - 2002-05-27 01:32:12
|
On Sunday, May 26, 2002, at 01:52 , Christopher Heiny wrote: > What Java compiler and VM are you using under which OS when you build > OpenJNLP and the associated jars? I'm beginning to think this weird > problem I'm using javac on Mac OS X via the ant <javac> task. Apple's Java implementation is Java2 1.3.1. |
|
From: Christopher H. <he...@ez...> - 2002-05-26 06:54:19
|
Kevin, What Java compiler and VM are you using under which OS when you build OpenJNLP and the associated jars? I'm beginning to think this weird problem I'm experiencing with the java.lang.VerifyError is either related to my installation or is the product of mixing compilers - this suspicion is reinforced by the fact that when I recompiled the latest Jext sources, the same problem occurs. Thanks, Chris |
|
From: Jeff A. <je...@wo...> - 2002-05-17 18:35:23
|
Apologies, I meant to send the URL: more useful is section 4.2 (page 24) of: http://access1.sun.com/SRDs/srd_repository/1.4_plugin.pdf Sorry, Jeff |
|
From: Jeff A. <je...@wo...> - 2002-05-17 18:33:34
|
At 11:37 AM -0400 5/17/02, Scott Kovatch wrote: >On Thursday, May 16, 2002, at 10:13 PM, Kevin Herrboldt wrote: > >>On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote: >> >>>That's fine -- those additional methods are only used by the Java >>>Plugin on 1.4 -- AppletRunner would only need those to satisfy the >>>interface and nothing else. >> >>I went ahead and implemented the methods to actually do stuff, >>since it was pretty straightforward using collections. >> >>Do you know how these methods are used or what Sun's intention is? >>Seems odd Sun would add these to the AppletContext interface just >>for the Java Plugin. Now they're exposed to the applet itself >>through Applet.getAppletContext, so I can see applet writers using >>them. > >They're related to JavaBeans -- I believe there's a feature of the >plugin that allows you to wrap a Java Bean as an ActiveX control, so >there's a pile of code that treats JavaBeans like applets. As a >security measure you don't want components reading from or writing >to each others streams, so this is how they keep them separate. > >That's a 10-minute reading-of-the-code analysis, so I may be wrong. >But, you're implementation sounds like it matches what's in the >plugin. I doubt it will ever get used, though. > >Scott > >_____________________ >Scott Kovatch >Java Runtime Classes >Apple Computer >Cleveland Hts, OH >sko...@ap... > Actually, there is some documentation on what they can be used for by applets that want to basically persist anything longer than a single session, and some sample code at: http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/persistence.html more useful is section 4.2 (page 24) of: http://internal.wolfram.com/~jeffa/java/api/1.4_plugin.pdf Jeff |
|
From: Kevin H. <ke...@na...> - 2002-05-17 16:36:28
|
On Friday, May 17, 2002, at 11:08 , Christopher Heiny wrote: [...] > I picked up your latest check in, and the VerifyError is still there. > Web I haven't gotten the new FileCachedEntry checked in, sorry. I ran into a snag but will get it done today. I'll try compiling under Java 1.4 on one of my linux boxen and see what I get. > searching seems to indicate that it might be a conflict between things > compiled with Blackdown or Jikes and the Sun JVM. At any rate, the JVM > is > not happy with something relating to line 276, but unfortunately the > error > message is way to nebulous. How do I determine which compiler Ant is > using > in the builds? I dunno, use "ant -debug", that usually causes copious amounts of output. The ant rule for OpenJNLP compiling uses the default compiler in the <javac> task as far as I know (no special setting for selecting compiler). |
|
From: Christopher H. <he...@ez...> - 2002-05-17 16:09:56
|
Thanks for completing that implementation. I picked up your latest check in, and the VerifyError is still there. Web searching seems to indicate that it might be a conflict between things compiled with Blackdown or Jikes and the Sun JVM. At any rate, the JVM is not happy with something relating to line 276, but unfortunately the error message is way to nebulous. How do I determine which compiler Ant is using in the builds? Another way the message can result is through misuse of scoping loopholes in the language, or compiler bugs related to scoping. I'm going to try constructing a test case with a similar set of relationships between the classes, to see if that will barf in the same spot. Chris |
|
From: Christopher H. <he...@ez...> - 2002-05-17 15:51:22
|
On Friday 17 May 2002 08:37 am, Scott Kovatch wrote: > They're related to JavaBeans -- I believe there's a feature of the plugin > that allows you to wrap a Java Bean as an ActiveX control, so there's a > pile of code that treats JavaBeans like applets. As a security measure you > don't want components reading from or writing to each others streams, so > this is how they keep them separate. > > That's a 10-minute reading-of-the-code analysis, so I may be wrong. But, > you're implementation sounds like it matches what's in the plugin. I doubt > it will ever get used, though. That is my understanding of their primary purpose, based on a similar quick scan of things. There is a nagging idea in the back of my head that this is also intended for use in visual bean IDEs. That may just be the product of all the Nyquil I've been taking lately (I >hate< having the flu in May :-) ). Chris |
|
From: Scott K. <sko...@ap...> - 2002-05-17 15:38:09
|
On Thursday, May 16, 2002, at 10:13 PM, Kevin Herrboldt wrote: > On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote: > >> That's fine -- those additional methods are only used by the Java Plugin on 1.4 -- AppletRunner would only need those to satisfy the interface and nothing else. > > I went ahead and implemented the methods to actually do stuff, since it was pretty straightforward using collections. > > Do you know how these methods are used or what Sun's intention is? Seems odd Sun would add these to the AppletContext interface just for the Java Plugin. Now they're exposed to the applet itself through Applet.getAppletContext, so I can see applet writers using them. They're related to JavaBeans -- I believe there's a feature of the plugin that allows you to wrap a Java Bean as an ActiveX control, so there's a pile of code that treats JavaBeans like applets. As a security measure you don't want components reading from or writing to each others streams, so this is how they keep them separate. That's a 10-minute reading-of-the-code analysis, so I may be wrong. But, you're implementation sounds like it matches what's in the plugin. I doubt it will ever get used, though. Scott _____________________ Scott Kovatch Java Runtime Classes Apple Computer Cleveland Hts, OH sko...@ap... |
|
From: Kevin H. <ke...@na...> - 2002-05-17 02:13:54
|
On Tuesday, May 14, 2002, at 08:22 , Scott Kovatch wrote: > That's fine -- those additional methods are only used by the Java > Plugin on 1.4 -- AppletRunner would only need those to satisfy the > interface and nothing else. I went ahead and implemented the methods to actually do stuff, since it was pretty straightforward using collections. Do you know how these methods are used or what Sun's intention is? Seems odd Sun would add these to the AppletContext interface just for the Java Plugin. Now they're exposed to the applet itself through Applet.getAppletContext, so I can see applet writers using them. |
|
From: Kevin H. <ke...@na...> - 2002-05-16 18:51:27
|
On Thursday, May 16, 2002, at 01:03 , Christopher Heiny wrote: [...] > [I suspect my mailer will break the wrap on this - sorry] At any rate, > I'm a > little baffled by the line > String path = reference.getURL().getPath(); > I don't find reference defined anywhere in the file - do you mean "ref" > instead? Or is this an aspect of Java that I don't understand? Look at the super abstract class, CachedResource. It has the "reference" variable. The super(ref) calls the constructor in CachedResource and sets "reference" to the argument. I don't get why this would break on Java 1.4. The stack trace isn't much help. Okay, now that I've explained what's going on... I completely rewrote FileCachedEntry last night. I just have to do a couple more things to make it work and then I'll check it in. |
|
From: Christopher H. <he...@ez...> - 2002-05-16 06:04:25
|
Hi Kevin,
I've bumped into something. In FileCacheEntry.java, near line 548 of the
version checked into CVS (we're in the constructor for FileCachedResource), I
find the following lines:
/**
* Creates a cached resource in the resource dir for the specified
reference.
*
* @param ref the reference to cache
*/
FileCachedResource(Reference ref) {
super(ref);
String path = reference.getURL().getPath();
cacheFile = new File(getResourceDir(),
path.substring(path.lastIndexOf("/")));
}
[I suspect my mailer will break the wrap on this - sorry] At any rate, I'm a
little baffled by the line
String path = reference.getURL().getPath();
I don't find reference defined anywhere in the file - do you mean "ref"
instead? Or is this an aspect of Java that I don't understand?
What's happening on my system, using Sun's JDK 1.4.0, is that execution gets
to the initializer for FileCachedResource, and then throws a
java.lang.VerifyError, like so:
[cheiny@anomalocaris targets]$ openjnlp.sh ~/jpathreport.jnlp
Opening file:/home/cheiny/jpathreport.jnlp
Exception in thread "main" java.lang.VerifyError: (class:
org/nanode/launcher/cache/FileCacheEntry$FileCachedResource, method: <init>
signature:
(Lorg/nanode/launcher/cache/FileCacheEntry;Lorg/nanode/launcher/Reference;J)V)
Expecting to find object/array on stack
at
org.nanode.launcher.cache.FileCacheEntry.addResource(FileCacheEntry.java:276)
at org.nanode.jnlp.JNLPParser.parseDescriptor(JNLPParser.java:302)
at
org.nanode.app.openjnlp.DefaultAppHandler.handleOpenURL(DefaultAppHandler.java:72)
at org.nanode.app.OpenJNLP.main(OpenJNLP.java:83)
[cheiny@anomalocaris targets]$
I >think< there is something funky going on with that "reference", but I must
confess bafflement at this point. Can you provide enlightenment?
Thanks!
Chris
|
|
From: Christopher H. <he...@ez...> - 2002-05-15 07:22:09
|
The first iteration of Elvis is available at http://sourceforge.net/projects/javaelvis. This doesn't yet attempt to address the security concerns we talked about earlier. I'll probably turn it through one more iteration before embarking on the OpenJNLP integration. Feel free, though, to check it out, and let me know of any improvements that can be made. Chris |
|
From: Scott K. <sko...@ap...> - 2002-05-15 01:22:51
|
That's fine -- those additional methods are only used by the Java Plugin on 1.4 -- AppletRunner would only need those to satisfy the interface and nothing else. Scott K. On Tuesday, May 14, 2002, at 09:16 PM, Christopher Heiny wrote: > I had to tweak AppletRunner.java to get it to compile correctly under > JDK 1.4 > Basically, there are 3 methods in the AppletContext interface that are > new > with that JDK - I just stubbed them to return null (if they aren't > void), and > commented them as incompletely implemented. They're checked into CVS > just to > avoid divergence. _____________________ Scott Kovatch Java Runtime Classes Apple Computer Cleveland Hts, OH sko...@ap... "We're going to need some glue and a ten minute head start." - Baby Blues |
|
From: Christopher H. <he...@ez...> - 2002-05-15 01:16:20
|
I had to tweak AppletRunner.java to get it to compile correctly under JDK 1.4 Basically, there are 3 methods in the AppletContext interface that are new with that JDK - I just stubbed them to return null (if they aren't void), and commented them as incompletely implemented. They're checked into CVS just to avoid divergence. Chris |
|
From: Christopher H. <he...@ez...> - 2002-05-13 04:02:14
|
On Sunday 12 May 2002 01:20 pm, Kevin Herrboldt wrote: > ...This falls into the "security by > obscurity" category and seems more secure than it actually is. I'm not > saying it's a bad thing to do, but I'd recommend focusing more on secure > message passing. I agree, somewhat. However, it's very easy to implement (three lines of code), and I generally tend to favor anything that makes life more difficult to the casual cracker. It's not so much "security through obscurity" as "slightly increased security through increased hassle". The more of a pain you make things for script-kiddies, the less likely they are to trouble you. This means you can devote more of those lying-awake-worrying nights to the serious cracker. Also, at least on the machine I'm using at the moment (running Mandrake 8.2 x86 distro), doesn't reveal anything particularly Elvis related about the port, although it is possible to identify that a java program of some kind is using the port. An attacker would still have to probe a number of possible ports in an attempt to spoof Elvis - thus increasing his exposure and risk of detection. Yeh, I know, 99% of the population doesn't do anything to detect such attacks anyway.... >Is Elvis listening on 127.0.0.1 only? I have no idea how I could have been so stupid as to miss that, but I did. Thanks! Chris |
|
From: Kevin H. <ke...@na...> - 2002-05-12 21:16:13
|
There were a lot of problems with resource updating being done too often. Turns out it had to do with duplicate entries being in the resource map, which can be noticed by duplicate entries in entry.xml files. As an example, I use Cicerone (http://www.puppethead.com/java/apps/Cicerone.jnlp) for testing and I had cicerone.jar listed 83 times in the entry.xml file. Ugh. Anyway, it's been fixed by using the URL as the key in the resource map instead of the Reference, which has mutable properties like version and laziness. Just because a jar becomes lazy doesn't change the jar that's in the cache. People should notice quite an improvement in launching since cached resources are actually being used. My testing shows the entry.xml file cleans itself up when you launch an app. |
|
From: Kevin H. <ke...@na...> - 2002-05-12 20:59:52
|
On Thursday, May 9, 2002, at 01:57 , Mario Cormier wrote:
> Are there any plans to support background downloading of newer versions
> when
> there exists a working version in the cache? For instance, in section
> 1.2.2
> of the spec it says "a JNLP client can download an updated version in
> the
> background, while the already-downloaded version is being used". (They
> seem
> to imply that you need to use the version-based protocol to be able to
> do
> that, but I fail to see why you would NEED it.)
That's exactly how I read the spec as well, and my admittedly limited
testing with JWS seems to show the run current/download new behavior is
only for version-based resources, not basic.
If you think about it, it does make sense. You don't want the background
download to modify the jars of the version you're running. The way I
view things a basic (unversioned) resource is just a special version. So
downloading out-of-date jars is updating jars within that version, not
getting a different version. You'd have the same scenario if you're
using foo.jar version 1.2 and it's out of date, but still version 1.2.
> I think having support for that would provide much faster startup times
> when
> the network is slow. I could implement it myself, but I think it might
> require small changes all over the place so if it's already in the
> plans or
> if someone is already tackling this issue, I suppose I can wait. Any
> suggestions on how to go about this?
I've been giving thoughts as to how to add versioned resources to
OpenJNLP. I think versioning needs to be implemented before any
background upgrading can happen.
My thoughts on versioning so far are:
1) Multiple versions of an app can co-exist within the same cache entry.
This means multiple versions of the same jar within the "Resources"
directory. I think attaching the version-id to the resource file name
will accomplish uniqueness. The basic version would simply be the
resource name.
2) Basic (unversioned) resources are considered a unique version.
3) Updating an out-of-date resource does not change the version.
4) The version of a resource used for an app is determined by the jnlp
file, which may also be versioned.
5) I think the entry.xml file would get updated to move the <resource>
and <nativelib> entries inside a <version> tag or somesuch. A possible
example is:
<entry vendor="Foo" title="Bar">
<version id="1.2">
<resource href="http://www.foo.org/bar.jar" version="1.0"
modtime="12345" />
</version>
<version id="1.1">
...
</version>
</entry>
I think it needs more thought/discussion before any implementation is
done. But most importantly I'd like to get a new release of OpenJNLP
done first. There are already a lot of big fixes/changes "in the can"
that should be rolled out as an official version.
|
|
From: Kevin H. <ke...@na...> - 2002-05-12 20:22:48
|
On Thursday, May 9, 2002, at 01:21 , Kevin Herrboldt wrote: [...] > I'll get the rest of it done later today/tonight, including the > nativelib stuff. I've worked on This is all done and was committed to cvs, in case it was missed by any interested parties. |
|
From: Kevin H. <ke...@na...> - 2002-05-12 20:21:00
|
On Saturday, April 27, 2002, at 03:20 , Christopher Heiny wrote: [...] > 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). This sounds good, but isn't necessarily. It's pretty simple to just run "netstat -a" to see what ports are being listened to. And if you're listening only on 127.0.0.1 it's even more obvious, since there are so few things restricted to 127.0.0.1. This falls into the "security by obscurity" category and seems more secure than it actually is. I'm not saying it's a bad thing to do, but I'd recommend focusing more on secure message passing. > 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. Is Elvis listening on 127.0.0.1 only? If so, there is no way a connection can come from anywhere than 127.0.0.1. Well, okay, technically maybe any interface on the current machine but certainly not an interface from a different machine. |
|
From: Mario C. <mar...@po...> - 2002-05-09 18:54:23
|
Are there any plans to support background downloading of newer versions when there exists a working version in the cache? For instance, in section 1.2.2 of the spec it says "a JNLP client can download an updated version in the background, while the already-downloaded version is being used". (They seem to imply that you need to use the version-based protocol to be able to do that, but I fail to see why you would NEED it.) I think having support for that would provide much faster startup times when the network is slow. I could implement it myself, but I think it might require small changes all over the place so if it's already in the plans or if someone is already tackling this issue, I suppose I can wait. Any suggestions on how to go about this? Mario |
|
From: Kevin H. <ke...@na...> - 2002-05-09 18:21:20
|
On Thursday, May 9, 2002, at 12:05 , Mario Cormier wrote: > 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 Yeah, I just got the background loading and findClass() checking done. I have to work on non-OpenJNLP things during the day and I do need to sleep regularly. I'll get the rest of it done later today/tonight, including the nativelib stuff. I've worked on software that does this kind of thing before, so that's why I was able to get it in there so quickly. I just needed someone to give me a kick in the butt to address the issue. |
|
From: Kevin H. <ke...@na...> - 2002-05-09 18:00:12
|
On Wednesday, May 8, 2002, at 04:44 , Mario Cormier wrote: > 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 I went back and carefully re-read the spec, I now agree with your interpretation. Caching is always optional. I don't want to treat lazy resources as eager because that could be a horrible performance issue at startup time. Your approach with directly accessing lazy resources via HTTP would be better. However, I have a better idea... I've modified the classloader to cache lazy resources in a separate thread if any exist. This is done by the constructor, so lazy resources are cached right away but still allow the app to start running. I modified findClass() to wait for lazy resources to be updated before failing on not finding a class. Only after all lazy resources are up to date and the class is not found will the ClassNotFoundException be thrown. |