openjnlp-devel Mailing List for OpenJNLP (Page 5)
Brought to you by:
kherr
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-02-18 19:54:10
|
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. 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. 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 Windows, when trying to tie ".jnlp" files to OpenJNLP, I found that when Windows opens the file the current directory is where the ".jnlp" file is, not the OpenJNLP.bat location. There's no way to know where the "home" of OpenJNLP is. Some strategies I've considered are: 1) Write a registry key value for the install location -JWS does this, it's very Windows-ish but it also requires special code -what happens with multiple installs? 2) Have OpenJNLP write something to a file like "${user.home}/.jnlp/openjnlp.properties" identifying where the home directory is -the batch file would need to be modified, is it possible to parse props files from DOS? -what happens with multiple installs? 3) Use "${java.class.path}" to find the actual location of the jars needed for the launcher -the "${launch.classpath}" property would be supplanted by a list of needed jars -the Launcher would be updated to pick those jars out of the current classpath -multiple installs are not an issue 4) Copy the launcher jars into a known location like "${user.home}/.jnlp/launcher" so they are in a known location -breaks if running in a read-only environment -creates updating issues -eliminates multiple install problem -enables OpenJNLP to be launched via Java Web Start I'm kind of favoring option 3 as the cleanest. Any and all feedback welcome. Now some random thoughts that are somewhat related to this: -Getting OpenJNLP to work as a JNLP app is powerful, and I think important to supplant JWS, especially with Java2 1.4 now out. -The JNLP-borne version of OpenJNLP could just be an installer, therefore running within JWS would not be an issue for launching. -Mac OS Classic launching is not really an issue, since it has a very specific solution. There is also going to be a new Java 1.1 product for OpenJNLP and that will be the place where Mac OS Classic launching needs to be. OpenJNLP doesn't need it since it's Java2 only. -On Windows OpenJNLP will need to modify the registry somehow anyway to set up the document mapping. It also needs to be done on Mac OS X. I've already investigated both of these and have JNI-style Java interfaces into the necessary calls figured out (for the most part). -I'd like to do some integrating of OpenJNLP into KDE or Gnome or both on linux. I don't really know how either desktop environment is structured for doing mappings and icons and stuff, so any ideas here would be awesome. I'm ambivelant about Solaris and CDE. -JavaWorld has tips on self-executing jars where basically you embed all of your app as resources in a jar and then write a Java extraction utility that is identified as the main-class in the manifest. This would enable the "install" of OpenJNLP by double-clicking the jar. I see this as a possible excellent solution for guaranteeing Java is present before OpenJNLP gets installed, since the jar won't execute without Java. This installer could also be used as the JNLP installer for JWS. Thoughts? There. Launching issues aren't so simple, are they? |
From: Christopher H. <he...@ez...> - 2002-02-18 04:27:43
|
Hi Kevin, all 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). 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> For example, launcher.main.unix, and synthesize the names based on OS flavor before looking them up. This means that the info will no longer be user editable, but I'm not sure that's a good idea anyways. On the other hand, it would probably enable the discard of the fancy Mac OS classic code in Launcher. Thanks, Chris |
From: Kevin H. <ke...@na...> - 2002-01-14 07:09:12
|
The OpenJNLP code has just undergone major refactoring to provide conceptual clarity and lay the groundwork for future functionality. The biggest and most confusing refactoring is in org.nanode.launcher. The org.nanode.launcher.Reference class has been completely scrapped, rolling all its functionality into the org.nanode.launcher.Descriptor class. A JNLP file gets parsed into a Descriptor, which is what the Launcher now acts on. This is more sensible architecturally than the former arrangement. Descriptor gets extended for specific types of descriptors, such as ApplicationDescriptor (which no longer has anything to do with applets). Confusingly, however, there is a new org.nanode.launcher.Reference class that is a reference to a resource. It encapsulates a URL and version-id info. Moving to the Reference over straight URLs will allow version-based resource handling. All of the OpenJNLP source has been updated to reflect these changes, so everything should function as before. Some other improvements have been made, such as correctly supporting locale, arch and os restrictions on information and resources in the JNLP files. Hopefully this major refactoring won't cause too much pain to anyone. It needed to be done to provide a more understandable and sensible codebase moving forward. |
From: Daryl Robbins/M. T. <dar...@mx...> - 2002-01-03 21:11:32
|
Greetings, Has anyone attempted to run OpenJNLP on mobile devices supporting Java (i.e. under Savaje on an iPaq). Savaje supports only a small feature-set of the entire JNLP specification. If not, should it work in theory? Thank you. /Daryl Robbins |
From: Kevin H. <ke...@na...> - 2001-12-18 18:10:42
|
On Tuesday, December 18, 2001, at 09:32 , Gary Mangum wrote: > Now that I look closer, it doesn't look like you support 'extension' > yet. Sorry, not yet. Also no native libs. This is going in the next version, which I will be diligently working on during the holidays. Hopefully your wait won't be too long. |
From: Kevin H. <ke...@na...> - 2001-12-15 19:36:09
|
On Saturday, December 15, 2001, at 10:25 , Daniel Hoppe wrote: [...] > I recognized that too, the application was there and could be launched > after > restarting the OpenJNLP. Any chance that it's a GUI refresh bug? Yes, an annoying GUI refresh bug found its way into this release. Will be fixed ASAP. |
From: Daniel H. <ho...@si...> - 2001-12-15 16:26:22
|
>> Also, when I try to launch any of the JNLP files listed at the = OpenJNLP >> web site, I don't get any errors, however, the app doesn't launch >> either. >[...] > >Can you provide some more information? What OS and version of Java are = >you using? Are there any errors on the console? (On Windows you need = to=20 >edit the OpenJNLP.bat file to see java messages.) Are you using a = proxy?=20 >OpenJNLP doesn't support proxies yet. Hi, I recognized that too, the application was there and could be launched = after restarting the OpenJNLP. Any chance that it's a GUI refresh bug?=20 Daniel <<<<<<<<<<<<<<<<<<<<<<<<<<< sitewaerts GmbH Hebelstra=DFe 15 D-76133 Karlsruhe Tel: +49 (721) 920 918 0 Fax: +49 (721) 920 918 29 http://www.sitewaerts.de >>>>>>>>>>>>>>>>>>>>>>>>>>> |
From: Kevin H. <ke...@na...> - 2001-12-14 20:47:00
|
On Friday, December 14, 2001, at 09:16 , Gary Mangum wrote: > Was there an answer to this question? I get the same error message > everytime I attempt to launch my own JNLP files also. My JNLP files > work great with JavaWebStart. Answer posted in separate message. > Also, when I try to launch any of the JNLP files listed at the OpenJNLP > web site, I don't get any errors, however, the app doesn't launch > either. [...] Can you provide some more information? What OS and version of Java are you using? Are there any errors on the console? (On Windows you need to edit the OpenJNLP.bat file to see java messages.) Are you using a proxy? OpenJNLP doesn't support proxies yet. |
From: Kevin H. <ke...@na...> - 2001-12-14 20:42:07
|
On Thursday, December 13, 2001, at 03:28 , Daniel Hoppe wrote: [...] > quite interesting. Right now I've got the problem that it tells me that > there is a "problem Retrieving - unknown start tag property" when I try > to > launch my application. Does it mean the <property> tags in my JNLP > file? I'm > using quite a complex jnlp file (see below), with a bunch of jars, a > nativelib, properties and arguments. Are these already supported? It > would > be nice if someone could give me some kind of status on what is > supposed to > work so far. Please copy me directly, I'm not subscribed to the list > yet. [...] Thanks for the feedback, there is definately a bug with OpenJNLP, your <property> tags should parse fine. I've already identified the problem and will get a fix done ASAP. The <property> and <nativelib> tags are parsed but do not have any effect when launching. Arguments are handled correctly. Properties can be added simply, I'll see if I can get nativelibs working. Look for these things in a new release early next week. |
From: Gary M. <ga...@ui...> - 2001-12-14 15:17:54
|
V2FzIHRoZXJlIGFuIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uPyAgSSBnZXQgdGhlIHNhbWUgZXJy b3IgbWVzc2FnZQ0KZXZlcnl0aW1lIEkgYXR0ZW1wdCB0byBsYXVuY2ggbXkgb3duIEpOTFAgZmls ZXMgYWxzby4gIE15IEpOTFAgZmlsZXMNCndvcmsgZ3JlYXQgd2l0aCBKYXZhV2ViU3RhcnQuDQpB bHNvLCB3aGVuIEkgdHJ5IHRvIGxhdW5jaCBhbnkgb2YgdGhlIEpOTFAgZmlsZXMgbGlzdGVkIGF0 IHRoZSBPcGVuSk5MUA0Kd2ViIHNpdGUsIEkgZG9uJ3QgZ2V0IGFueSBlcnJvcnMsIGhvd2V2ZXIs IHRoZSBhcHAgZG9lc24ndCBsYXVuY2gNCmVpdGhlci4NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KCUZyb206IERhbmllbCBIb3BwZSANCglTZW50OiBUaHUgMTIvMTMvMjAwMSAyOjI4 IFBNIA0KCVRvOiAnb3BlbmpubHAtZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0JyANCglDYzog DQoJU3ViamVjdDogW09wZW5qbmxwLWRldmVsXSBRdWVzdGlvbiBhYm91dCBPcGVuSk5MUA0KCQ0K CQ0KDQoJSGkgSk5MUGxlcnMsDQoJDQoJSSd2ZSBnb3QgYSBxdWVzdGlvbiByZWdhcmRpbmcgdGhl IHN0YXR1cyBvZiBPcGVuSk5MUC4gSSd2ZSBnb3QNCmFuDQoJYXBwbGljYXRpb24gd2hpY2ggdXNl cyBXZWJTdGFydCBzbyBmYXIgYW5kIEkganVzdCBmb3VuZCB0aGUNCm1lc3NhZ2UNCglhbm5vdW5j aW5nIE9wZW5KTkxQIG9uIHRoZXNlcnZlcnNpZGUuY29tLiBJIGRlY2lkZWQgdG8gZ2l2ZSBpdCBh DQp0cnksIHNvdW5kcw0KCXF1aXRlIGludGVyZXN0aW5nLiBSaWdodCBub3cgSSd2ZSBnb3QgdGhl IHByb2JsZW0gdGhhdCBpdCB0ZWxscw0KbWUgdGhhdA0KCXRoZXJlIGlzIGEgInByb2JsZW0gUmV0 cmlldmluZyAtIHVua25vd24gc3RhcnQgdGFnIHByb3BlcnR5Ig0Kd2hlbiBJIHRyeSB0bw0KCWxh dW5jaCBteSBhcHBsaWNhdGlvbi4gRG9lcyBpdCBtZWFuIHRoZSA8cHJvcGVydHk+IHRhZ3MgaW4g bXkNCkpOTFAgZmlsZT8gSSdtDQoJdXNpbmcgcXVpdGUgYSBjb21wbGV4IGpubHAgZmlsZSAoc2Vl IGJlbG93KSwgd2l0aCBhIGJ1bmNoIG9mDQpqYXJzLCBhDQoJbmF0aXZlbGliLCBwcm9wZXJ0aWVz IGFuZCBhcmd1bWVudHMuIEFyZSB0aGVzZSBhbHJlYWR5DQpzdXBwb3J0ZWQ/IEl0IHdvdWxkDQoJ YmUgbmljZSBpZiBzb21lb25lIGNvdWxkIGdpdmUgbWUgc29tZSBraW5kIG9mIHN0YXR1cyBvbiB3 aGF0IGlzDQpzdXBwb3NlZCB0bw0KCXdvcmsgc28gZmFyLiBQbGVhc2UgY29weSBtZSBkaXJlY3Rs eSwgSSdtIG5vdCAgc3Vic2NyaWJlZCB0byB0aGUNCmxpc3QgeWV0Lg0KCQ0KCUNoZWVycywNCgkN CglEYW5pZWwNCgkNCgk8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/Pg0KCTxq bmxwIHNwZWM9IjEuMCIgY29kZWJhc2U9Ii4uLiIgaHJlZj0iZmJzX2NjXzNfMC5qbmxwIj4NCgkg ICAgICAgIDxpbmZvcm1hdGlvbj4NCgkgICAgICAgICAgICAgICAgPHNuaXBwZWQgbWFya2V0aW5n IGJsYWJsYSAvPg0KCSAgICAgICAgPC9pbmZvcm1hdGlvbj4NCgkgICAgICAgIDxzZWN1cml0eT4N CgkgICAgICAgICAgICAgICAgPGFsbC1wZXJtaXNzaW9ucy8+DQoJICAgICAgICA8L3NlY3VyaXR5 Pg0KCSAgICAgICAgPHJlc291cmNlcz4NCgkgICAgICAgICAgICAgICAgPGoyc2UgdmVyc2lvbj0i MS4zKyIgaW5pdGlhbC1oZWFwLXNpemU9Ijk5bSINCgltYXgtaGVhcC1zaXplPSIyNTZtIi8+DQoJ ICAgICAgICAgICAgICAgIDxqYXIgaHJlZj0iZmJzX2NjX2ljZV93bDYxLmphciIgbWFpbj0idHJ1 ZSIvPg0KCSAgICAgICAgICAgICAgICA8amFyIGhyZWY9InNheG9uLmphciIgZG93bmxvYWQ9ImVh Z2VyIi8+DQoJICAgICAgICAgICAgICAgIDxqYXIgaHJlZj0id2Vya2VuLm9wdC5qYXIiIGRvd25s b2FkPSJlYWdlciIvPg0KCSAgICAgICAgICAgICAgICA8amFyIGhyZWY9ImxvZzRqLmphciIgZG93 bmxvYWQ9ImVhZ2VyIi8+DQoJICAgICAgICAgICAgICAgIDxqYXIgaHJlZj0iamJjbDMuMS5qYXIi IGRvd25sb2FkPSJlYWdlciIvPg0KCSAgICAgICAgICAgICAgICA8amFyIGhyZWY9Impkb20uamFy IiBkb3dubG9hZD0iZWFnZXIiLz4NCgkgICAgICAgICAgICAgICAgPGphciBocmVmPSJ3ZXJrZW4u eHBhdGguamFyIiBkb3dubG9hZD0iZWFnZXIiLz4NCgkgICAgICAgICAgICAgICAgPGphciBocmVm PSJISUdMYXlvdXQuamFyIiBkb3dubG9hZD0iZWFnZXIiLz4NCgkgICAgICAgICAgICAgICAgPGph ciBocmVmPSJ3ZWJsb2dpYy5qYXIiIGRvd25sb2FkPSJlYWdlciIvPg0KCSAgICAgICAgICAgICAg ICA8amFyIGhyZWY9Impha2FydGEtcmVnZXhwLTEuMS5qYXIiDQpkb3dubG9hZD0iZWFnZXIiLz4N CgkgICAgICAgICAgICAgICAgPG5hdGl2ZWxpYiBocmVmPSJmdXR1bmFfbmF0aXZlLmphciINCmRv d25sb2FkPSJlYWdlciIvPg0KCSAgICAgICAgICAgICAgICA8cHJvcGVydHkNCm5hbWU9ImphdmF4 LnhtbC50cmFuc2Zvcm0uVHJhbnNmb3JtZXJGYWN0b3J5Ig0KCXZhbHVlPSJjb20uaWNsLnNheG9u LlRyYW5zZm9ybWVyRmFjdG9yeUltcGwiLz4NCgkgICAgICAgICAgICAgICAgPHByb3BlcnR5DQpu YW1lPSJqYXZheC54bWwucGFyc2Vycy5Eb2N1bWVudEJ1aWxkZXJGYWN0b3J5Ig0KCXZhbHVlPSJ3 ZWJsb2dpYy5hcGFjaGUueGVyY2VzLmpheHAuRG9jdW1lbnRCdWlsZGVyRmFjdG9yeUltcGwiLz4N CgkgICAgICAgICAgICAgICAgPHByb3BlcnR5DQpuYW1lPSJqYXZheC54bWwucGFyc2Vycy5TQVhQ YXJzZXJGYWN0b3J5Ig0KCXZhbHVlPSJ3ZWJsb2dpYy5hcGFjaGUueGVyY2VzLmpheHAuU0FYUGFy c2VyRmFjdG9yeUltcGwiLz4NCgkgICAgICAgICAgICAgICAgPHByb3BlcnR5IG5hbWU9ImZicy5h c3N5c3RlbW5hbWUiIHZhbHVlPSJ3bDYxIi8+DQoJICAgICAgICAgICAgICAgIDxwcm9wZXJ0eSBu YW1lPSJmYnMuc3RyYXRlZ3kiIHZhbHVlPSJkZWZhdWx0Ii8+DQoJICAgICAgICAgICAgICAgIDxw cm9wZXJ0eSBuYW1lPSJmYnMuZGVwbG95bWVudCIgdmFsdWU9ImljZSIvPg0KCSAgICAgICAgPC9y ZXNvdXJjZXM+DQoJICAgICAgICA8YXBwbGljYXRpb24tZGVzYw0KCW1haW4tY2xhc3M9ImRlLnNp dGV3YWVydHMuZnV0dW5hLmNjLmFwcGxpY2F0aW9uLlN0YXJ0Ij4NCgkgICAgICAgICAgICAgICAg PGFyZ3VtZW50Pi0tc2lkPC9hcmd1bWVudD4NCgkgICAgICAgICAgICAgICAgPGFyZ3VtZW50Pmlj ZTwvYXJndW1lbnQ+DQoJICAgICAgICAgICAgICAgIDxhcmd1bWVudD4tLXVybDwvYXJndW1lbnQ+ DQoJICAgICAgICAgICAgICAgIDxhcmd1bWVudD4uLi48L2FyZ3VtZW50Pg0KCSAgICAgICAgPC9h cHBsaWNhdGlvbi1kZXNjPg0KCTwvam5scD4NCgkNCgk8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8 PDwNCglzaXRld2FlcnRzIEdtYkgNCglIZWJlbHN0cmHDn2UgMTUNCglELTc2MTMzIEthcmxzcnVo ZQ0KCQ0KCVRlbDogKzQ5ICg3MjEpIDkyMCA5MTggMA0KCUZheDogKzQ5ICg3MjEpIDkyMCA5MTgg MjkNCglodHRwOi8vd3d3LnNpdGV3YWVydHMuZGUNCgk+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCgkNCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCU9wZW5qbmxwLWRldmVsIG1haWxpbmcgbGlzdA0KCU9wZW5qbmxwLWRldmVsQGxpc3Rz LnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xp c3RpbmZvL29wZW5qbmxwLWRldmVsDQoJDQoNCg== |
From: Daniel H. <ho...@si...> - 2001-12-13 21:29:36
|
Hi JNLPlers, I've got a question regarding the status of OpenJNLP. I've got an application which uses WebStart so far and I just found the message announcing OpenJNLP on theserverside.com. I decided to give it a try, = sounds quite interesting. Right now I've got the problem that it tells me that there is a "problem Retrieving - unknown start tag property" when I try = to launch my application. Does it mean the <property> tags in my JNLP = file? I'm using quite a complex jnlp file (see below), with a bunch of jars, a nativelib, properties and arguments. Are these already supported? It = would be nice if someone could give me some kind of status on what is = supposed to work so far. Please copy me directly, I'm not subscribed to the list = yet. Cheers, Daniel <?xml version=3D"1.0" encoding=3D"utf-8"?> <jnlp spec=3D"1.0" codebase=3D"..." href=3D"fbs_cc_3_0.jnlp"> <information> <snipped marketing blabla /> </information> <security> <all-permissions/> </security> <resources> <j2se version=3D"1.3+" initial-heap-size=3D"99m" max-heap-size=3D"256m"/> <jar href=3D"fbs_cc_ice_wl61.jar" main=3D"true"/> <jar href=3D"saxon.jar" download=3D"eager"/> <jar href=3D"werken.opt.jar" download=3D"eager"/> <jar href=3D"log4j.jar" download=3D"eager"/> <jar href=3D"jbcl3.1.jar" download=3D"eager"/> <jar href=3D"jdom.jar" download=3D"eager"/> <jar href=3D"werken.xpath.jar" download=3D"eager"/> <jar href=3D"HIGLayout.jar" download=3D"eager"/> <jar href=3D"weblogic.jar" download=3D"eager"/> <jar href=3D"jakarta-regexp-1.1.jar" download=3D"eager"/> <nativelib href=3D"futuna_native.jar" download=3D"eager"/> <property name=3D"javax.xml.transform.TransformerFactory" value=3D"com.icl.saxon.TransformerFactoryImpl"/> <property name=3D"javax.xml.parsers.DocumentBuilderFactory" value=3D"weblogic.apache.xerces.jaxp.DocumentBuilderFactoryImpl"/> <property name=3D"javax.xml.parsers.SAXParserFactory" value=3D"weblogic.apache.xerces.jaxp.SAXParserFactoryImpl"/> <property name=3D"fbs.assystemname" value=3D"wl61"/> <property name=3D"fbs.strategy" value=3D"default"/> <property name=3D"fbs.deployment" value=3D"ice"/> </resources> <application-desc main-class=3D"de.sitewaerts.futuna.cc.application.Start"> <argument>--sid</argument> <argument>ice</argument> <argument>--url</argument> <argument>...</argument> </application-desc> </jnlp> <<<<<<<<<<<<<<<<<<<<<<<<<<< sitewaerts GmbH Hebelstra=DFe 15 D-76133 Karlsruhe Tel: +49 (721) 920 918 0 Fax: +49 (721) 920 918 29 http://www.sitewaerts.de >>>>>>>>>>>>>>>>>>>>>>>>>>> |
From: Kevin H. <ke...@na...> - 2001-12-03 18:33:00
|
On Monday, December 3, 2001, at 11:40 , David Yen wrote: > Hi ! > Is there any way to download class files (maybe not the whole > application) by using JNLP programmatically without using web browser? OpenJNLP is designed to be used as an embedded library as well as a standalone application. You could easily write a specialized client that would know what app(s) to look for. The OpenJNLP cache is designed around a "Reference", which contains details about an application (e.g., which jars, description, etc.). You could manually construct your own Reference and use that. Or, by taking advantage of the JNLPParser, just use a JNLP file and let the JNLPParser create the Reference. > Let me draw a scenario here. > > A is the control server and download server > B1, B2, B3 are the clients. > > When B1 boot it, it has some configuration file to tell the IP of > download server. A tell B1 to do something and B1 does not have the > necessary class, can B1 download class files off the A? JNLP is jar-based, not class-based. You'd have to package your classes into one or more jars. OpenJNLP just added last-modified date versioning, so it only downloads each jar only when a new version is available. With JNLP out-of-date jars are downloaded, not the entire app. The next version of OpenJNLP with last-modified versioning is in CVS right now and will be issued as a release within a couple of days. |
From: David Y. <ye...@ho...> - 2001-12-03 17:40:42
|
Hi ! Is there any way to download class files (maybe not the whole application) by using JNLP programmatically without using web browser? Let me draw a scenario here. A is the control server and download server B1, B2, B3 are the clients. When B1 boot it, it has some configuration file to tell the IP of download server. A tell B1 to do something and B1 does not have the necessary class, can B1 download class files off the A? The whole idea is "enterprise deployment". We don't want to maintain B group by hand. David. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp |
From: Kevin H. <ke...@na...> - 2001-11-21 18:52:23
|
On Wednesday, November 21, 2001, at 01:34 , Doug Zwick wrote: [...] > I guess I wasn't very clear. I'm looking for suggestions on > how I can hack the 0.4 class loader to handle native methods, > not asking your team to shuffle the schedule and move it up. > I feel bad enough dragging you away to answer these questions! Don't feel bad! I really appreciate getting direction from users who need features. User feedback helps to keep motivation high and development active (four months since the last release is terrible!). As to adding nativelib support I think I failed to respond clearly, actually. Here's basically what needs to be done: 1) The nativelib resource needs to be downloaded to the local filesystem. 2) System.loadLibrary() needs to be called with the path to the local version of the library. 3) calls to native methods provided by that library should magically work. You could accomplish this yourself within your own code as a short-term solution, I think. Especially since OpenJNLP doesn't have any security checking. [...] > Am I missing something? I thought that page was just the basics of > JNI, I could find nothing there on how the native code actually gets > loaded. If you have a link to a page on that subject, I would > appreciate your sharing it. Start here: <http://java.sun.com/docs/books/tutorial/native1.1/stepbystep/step5.html>. That should help. Finally, there is a good chance nativelib stuff will happen with OpenJNLP much, much sooner than expected. I've been in contact with some colleagues who've done a lot of work in this area and they've been providing some good insight. |
From: Doug Z. <dz...@ho...> - 2001-11-21 07:35:07
|
At 2:04 PM -0700 11/20/01, Kevin Herrboldt wrote: >The inner workings of handling native libraries is a bit involved, >especially for Java 1.1 platforms. Java2 class loaders can implement >ClassLoader.findLibrary() to return an appropriate location for the >nativelib, but this is not the case with Java 1.1. Trying to get >nativelib stuff working in OpenJNLP for both Java2 and Java 1.1 are high >on the list, but is it worth holding up the next release? I could go >either way since more and more people want nativelib support, but it's >difficult to test. I guess I wasn't very clear. I'm looking for suggestions on how I can hack the 0.4 class loader to handle native methods, not asking your team to shuffle the schedule and move it up. I feel bad enough dragging you away to answer these questions! >> pointers to documentation on the inner workings of a ClassLoader. > >A description of how native stuff works for Java 1.1 is at ><http://java.sun.com/docs/books/tutorial/native1.1/index.html>. Am I missing something? I thought that page was just the basics of JNI, I could find nothing there on how the native code actually gets loaded. If you have a link to a page on that subject, I would appreciate your sharing it. -DCZ |
From: Kevin H. <ke...@na...> - 2001-11-20 21:04:38
|
On Tuesday, November 20, 2001, at 12:26 , Doug Zwick wrote: [...] > I've just been looking at the recent update to FileCacheClassLoader, and > its one of the Java-2-only changes (java.net.URLClassLoader is 1.2+). We Yes, this is a temporary situation, as the JDK1.1 version of OpenJNLP is forking from the Java2 version. As soon as cache updating by last modified date is implemented (JNLP refers to this as "basic" downloading) the JDK1.1 target will be added. This should happen within a few days since the basic downloading is nearly done. > are getting pressure to demo something under OS 9. Is the limitation of > the old FileCacheClassLoader something that can be hacked around? I'm > not yet clear on why the old code is failing when a native method is > called. Any hints at a work-around would be greatly appreciated, or The inner workings of handling native libraries is a bit involved, especially for Java 1.1 platforms. Java2 class loaders can implement ClassLoader.findLibrary() to return an appropriate location for the nativelib, but this is not the case with Java 1.1. Trying to get nativelib stuff working in OpenJNLP for both Java2 and Java 1.1 are high on the list, but is it worth holding up the next release? I could go either way since more and more people want nativelib support, but it's difficult to test. > pointers to documentation on the inner workings of a ClassLoader. A description of how native stuff works for Java 1.1 is at <http://java.sun.com/docs/books/tutorial/native1.1/index.html>. |
From: Doug Z. <dz...@ho...> - 2001-11-20 06:27:03
|
> On Saturday, November 3, 2001, at 11:31 , Doug Zwick wrote: > > [...] > > I've got a Java app (Mac OS9) that uses a JNI library, and I'm trying > > to get it to > > work with OpenJNLP 0.4. As stated in the doc, this does not work (I'm > > getting an > [...] > > be a problem with the ClassLoader implementation. If this is the case, > > is there a > > mod I can apply to FileCacheClassLoader so my app can at least start > > hobbling along > > until native lib support is released? I looked in CVS and didn't see > > anything new > > since 0.4. > > You are absolutely correct about this, it is a limitation of OpenJNLP's > class loader. This is being added to the next version, which is making > progress. There are other things being done as well, the class loader > work hasn't started yet. I'd suspect you'll see some class loader > changes in CVS this week. I've just been looking at the recent update to FileCacheClassLoader, and its one of the Java-2-only changes (java.net.URLClassLoader is 1.2+). We are getting pressure to demo something under OS 9. Is the limitation of the old FileCacheClassLoader something that can be hacked around? I'm not yet clear on why the old code is failing when a native method is called. Any hints at a work-around would be greatly appreciated, or pointers to documentation on the inner workings of a ClassLoader. -DCZ |
From: Kevin H. <ke...@na...> - 2001-11-09 07:09:30
|
OpenJNLP remains committed to providing JNLP functionality on Java 1.1. With the recently-committed launching changes OpenJNLP no longer compiles on Java 1.1. Some Java2 stuff had already gotten into OpenJNLP with the 0.4 release. In order to provide the highest quality the time has come to split the Java 1.1 version from the Java2 version. The situation is short-term while a new 1.1-friendly build is put in place. The 1.1 source will be in the same source tree, but under different packages. The intent is that anyone on a Java 1.1 platform will be able to build only a 1.1 version of OpenJNLP while Java2 will be able to build both. |
From: Kevin H. <ke...@na...> - 2001-11-09 06:58:41
|
Improvements to launching have been committed. Following is a description of the changes. All platforms now rely on "openjnlp.properties" to indicate how to invoke an external virtual machine. These properties are loaded by org.nanode.launcher.Launcher but are not put into System.properties. The properties are: launch.cmd command to invoke java launch.classpath classpath needed for external launching launch.main class to invoke when launching; will be passed url(s) as args If launch.cmd is undefined then the Launcher will use "${java.home}/bin/java" as the command. External launching only uses openjnlp-lib.jar plus XML and jnlp stuff. The GUI (openjnlp-app.jar) is only used when initially invoked to provide the user interface. Launched apps are now in their own thread within their own thread group. The contextClassLoader is now being set. |
From: Doug Z. <dz...@ho...> - 2001-11-05 06:31:10
|
>On Saturday, November 3, 2001, at 11:31 , Doug Zwick wrote: > >[...] >> I've got a Java app (Mac OS9) that uses a JNI library, and I'm trying >> to get it to >> work with OpenJNLP 0.4. As stated in the doc, this does not work (I'm >> getting an >[...] >> be a problem with the ClassLoader implementation. If this is the case, >> is there a >> mod I can apply to FileCacheClassLoader so my app can at least start >> hobbling along >> until native lib support is released? I looked in CVS and didn't see >> anything new >> since 0.4. > >You are absolutely correct about this, it is a limitation of OpenJNLP's >class loader. This is being added to the next version, which is making >progress. There are other things being done as well, the class loader >work hasn't started yet. I'd suspect you'll see some class loader >changes in CVS this week. Thanks for the info. I'll keep an eye on CVS. -DCZ Doug Zwick, Schlumberger/GeoQuest / Personal email: mailto:dz...@sh... / Seismic Data Management Solutions/ WWW: http://members.home.com/dzwick / http://www.slb.com/ /------------------------------------------/ dz...@sl... / "Thank God we don't get all the Government ==============================/ we pay for." -- Will Rogers |
From: Kevin H. <ke...@na...> - 2001-11-04 05:53:42
|
On Saturday, November 3, 2001, at 11:31 , Doug Zwick wrote: [...] > I've got a Java app (Mac OS9) that uses a JNI library, and I'm trying > to get it to > work with OpenJNLP 0.4. As stated in the doc, this does not work (I'm > getting an [...] > be a problem with the ClassLoader implementation. If this is the case, > is there a > mod I can apply to FileCacheClassLoader so my app can at least start > hobbling along > until native lib support is released? I looked in CVS and didn't see > anything new > since 0.4. You are absolutely correct about this, it is a limitation of OpenJNLP's class loader. This is being added to the next version, which is making progress. There are other things being done as well, the class loader work hasn't started yet. I'd suspect you'll see some class loader changes in CVS this week. |
From: Doug Z. <dz...@ho...> - 2001-11-04 05:31:59
|
I've got a Java app (Mac OS9) that uses a JNI library, and I'm trying to get it to work with OpenJNLP 0.4. As stated in the doc, this does not work (I'm getting an UnsatisfiedLinkError exception thrown on the first native method invocation). I can work around being unable to distribute the native lib via JNLP, but being unable to invoke native methods is a problem. From reading Apple's java-dev list, it looks to be a problem with the ClassLoader implementation. If this is the case, is there a mod I can apply to FileCacheClassLoader so my app can at least start hobbling along until native lib support is released? I looked in CVS and didn't see anything new since 0.4. Or am I barking up the wrong tree here? I know that the native lib is loading OK, as I ran through the procedure in TN 1155, which reported it loading without error, and it runs fine when launched directly from the Finder. This suggests that the issue lies somewhere that OpenJNLP does things differently than a Finder launch, and FileCacheClassLoader fits the bill. Unfortunately, so do other things. The correspondent on java-dev suggested that the SecurityManager could be vetoing the native method call, but I do not see anyplace where OpenJNLP is installing a SecurityManager. Any suggestions would be greatly appreciated. |
From: Kevin H. <ke...@na...> - 2001-10-15 17:24:36
|
The OpenJNLP build architecture has been streamlined. Here is a list of changes: - Now requires Ant 1.4. - "devel/build" is where all builds go. Not in CVS, nothing here should be checked in. - "devel/targets" contains all building instructions, will create "devel/build". - Each "product" has a subdirectory under "devel/targets" (e.g., "OpenJNLP"). - To build a product, you can execute Ant within the product subdirectory. - To build all products, you execute Ant in the "devel/targets" directory. Specific notes on OpenJNLP: - Upgraded to NanoXML 2.0; XML is provided using sax2.jar and nanoxml-sax-2.0.jar. - OpenJNLP simplified into two jars: openjnlp-app.jar and openjnlp- lib.jar. - "openjnlp-app.jar" is primarily now just GUI-related portion of OpenJNLP. - "openjnlp-lib.jar" contains everything to parse/launch JNLP. It is self-contained. - "org.nanode.jnlp.JNLPParser" now has a main method that properly invokes OpenJNLP launching. This makes it much easier to embed OpenJNLP into other apps since "openjnlp-lib.jar" is the only jar needed. These build changes are part of the next distribution of OpenJNLP, which will address many of the functional issues that have been received by OpenJNLP users. No specific release date is known, but the goal is to have another release out in under 30 days. |