Community
Participate
Working Groups
An application built on the Rich Client Platform should be able to launch via Java Web Start (JNLP). There appear to be issues around the plug-in directory structure and the plug-in class loaders.
Nick, This looks more like a Platform/Core problem but I'll start with you as you have 'the big picture' on RCP.
Moving to Equinox for comment.
Victor, we are interested in running via JNLP but have not had time to look at the details. Can you point us in the right direction? Code/doc/issues would all be interesting.
I am also interested in running the eclipse runtime from Java Web Start. One requirement for JWS is that all application code is packaged into a set of JARs, see also Bug 43406. This differs from the standard style of extracting plugins into separate directories.
As far as I can tell (I am not expert on the Eclipse platform) there are several issues involved in launching an Eclipse based application over JNLP. The first is unavoidable; an Eclipse hosted application must run in a fully trusted environment (as opposed to the untrusted ("sandbox") or J2EE Application Client Environment). This is the only JNLP trust model that will allow use of custom class loaders and native libraries (JNLP API & Specification 1.0.1 section 5.6). All resources for a JNLP application must be in JAR files. This requirement conflicts with the features and plugin directories used to load resources by Eclipse's custom class loaders. It would appear that some modification of the Eclipse plugin class loaders would be required. This is where I think most of the work would need to be done and where I have very little knowledge about how Eclipse does things. Native libraries must be specified as such so that they will be loaded with a System.loadLibrary() call. This will at least be an issue for SWT. There is an article on launching SWT based applications with JNLP at http://www-106.ibm.com/developerworks/opensource/library/os-jws/. Martin Beuchi has done some work on these issues (http://www.choicemaker.com/EclipsePlugins.htm) and come up with two solutions: one of which cripples JNLP and the other of which cripples Eclipse plugins. In his first work around he uses JNLP to launch an application that downloads a file with the Eclipse application zipped up in it, unzips it to disk and then launches the Eclipse application. This solution makes unavailable the transparent update, incremental update and incremental download features of JNLP. In the second he uses a customized Eclipse startup program to load the plugins directly from jars without using the Eclipse plugin class loader (which delegates to the class loaders of depended on plugins) thus crippling some of the basic functionality of the Eclipse plugin system.
The work to run out of jars is starting (see comment 4) I don't think the loadLibrary call will be a particular issue. Perhaps if we make it so running out of jars works, someone out there could work through some of the JNLP-specific issues?
As my time permits, I will probably try to get Java Web Start running when running out of JARs works. This is, what comment 4 and my comments on bug 43406 were aiming at. I don't need SWT, however.
*** Bug 51042 has been marked as a duplicate of this bug. ***
Regarding comment 5 above: (a) Crippling the Eclipse plugin functionality -- meaning, if I understand correctly, making it impossible to load and upate plugins at run-time -- may be unavoidable in moving to a JNLP solution, since the application has no direct control over the caching of the JNLP Jars. (b) Afaik, the more fundamental problem here is that a JNLP application is not allowed to add and remove dependent components at run-time: the JNLP file must statically declare all the extensions on which it depends. See the following bug (which Sun marked "will not be fixed"): http://developer.java.sun.com/developer/bugParade/bugs/4908304.html
Does the JNLP mechnaism somehow prevent the creation of new classloaders? or the use of the filesystem? If so, we will not be happy. If this is allowed, then we should be able to do what we want. Also, I thought that there was a JNLP mechansim for getting more function.
No, as I mentioned in comment 5 as long as you are in the "fully trusted environment" you may both create class loaders and access the file system and network at will.
I see ... my apologies. JNLP loads the bootstrap classes, then the Eclipse plug-in functionality takes it from there, using the local filesystem in the usual way. Thanks a lot for clarifying.
Does anyone know where this is at? It seems as though 3697 has been closed - but I cant find any info on it anywhere. I am trying to get a eclipse rcp app running from java web start. Does anyone know if this is actually possible yet?
I've done some initial investigations. The idea was to get webstart to do the management of plugins. Unfortunately this failed because it is not possible to force a layout to files donwloaded by webstart, which causes problems to eclipse since we can not find the "plugins" folder and subdirectories. I'm thinking in investigating another way which would be the following: - start with Main only - provision the bundle in a "data area" (using our own technologies) which would be shaped like a regular eclipse install. - point Main to this area The problem with this approach is that if 10 apps are started using webstart then the 10 apps would get a copy of all the rcp plugins. Otherwise, webstart provides a "custom installer" but to our analysis of it, it seems to defeat the point of using webstart since the custom installer has to do everything. If someone knows about workaround, or JNLP "tricks" that we would not know please tell us.
Perhaps the following resources may have some hints: Sun JNLP FAQ: http://java.sun.com/products/javawebstart/faq.html Sun JNLP forum: http://forum.java.sun.com/forum.jsp?forum=38 Unofficial JNLP FAQ and discussion forum archive: http://webstartfaq.com/
Another resource: http://www-106.ibm.com/developerworks/opensource/library/os-jws/ This discusses how to launch an SWT app using JNLP, not an eclipse app, so it doesn't have answers to the problems discussed above. Thought it would be worth linking to anyway though.
Ultimately here, we need to know is how an eclipse RCP application can be run from Jars only - with no special structure on the filesystem. Is it an uberjar - several jars?? Is there some jiggery pokery required? Once we know that, then we will know how to Web Start it... (or even if its possible) The brief look I have had has shown that startup.jar is still looking for a "plugins" directory... which doesnt bode well.... -Nick
I think it is possible to run eclipse from webstart, however you may not get the install / update functions of eclipse, and the sharing among the base of RCP jars might not be optimal. Here are 3 directions to explore: Prereq to both solutions: each plugin must leave in its own jar. For example you will have "org.eclipse.osgi_3.0.0..jar", "org.eclipse.core.runtime_3.0.0.jar", etc... To start eclipse you don't want to use o.e.core.launcher.Main, but rather directly start osgi or use your own main program. To do so, use org.eclipse.core.runtime.adaptor.EclipseAdaptor, set the values for the config area. Note that you can pass some system properties when starting webstart -- Direction 1 -- Write a simple bundle that directly install the bundles from for example an http location. (you can try that today with eclipse in typing in the console the following line: install http://mySite/bar.jar). The framework will download the bundle for you and everything will be handled properly. However, by doing that you automatically back out of the support provided by webstart to update jars. -- Direction 2 -- List all the jars of your application in the jnlp file so they get downloaded by JNLP. Now you have to write a bundle that discovers downloaded jars from the webstart cache and install them. Note that I'm not sure if browsing the webstart cache is feasible and you would have to make sure that you don't reinstall runtime and osgi :-) -- Direction 3 -- Create an update site (containing the jars mentionned earlier), create a feature refering to these jars (note that there is magic flag to set on the feature so it does not unzip the plugins once downloaded - Dorian?). Then you may want to tweak the install/update so it downloads the jars into some writtable place, unless this can be done already (Dorian?). In the initial list of bundles to have provisionned by webstart, in complement of osgi and runtime, you need update.core and its prereqs. The installation from the update site is done by a special bundle you would write and that would use the install / update APIs. Here again you back out of the webstart install story, but you have install/update managing most of the bundles.
As per Pascal comments, the update manager can install features/plugins to any arbitrary location, as directed by the user. To leave plugins packaged as jar's, on each <plugin> element inside feature.xml set the unpack attribute to false ( <plugin .... unpack="false"/> )
I recently did a talk at a local user's group about RCP and JWS was the #1 question. I don't use JWS myself but it would be great if someone who does could explore these paths and recommend a working solution. From this informal survey it looks like people want to use a .jnlp link to install a full RCP application, and then to have it updated automatically. They're most familiar with the way JWS does updates so that's what they ask for, but it might be the case that as long as updates work they won't care about how it's done (JWS way vs. Update Manager way). Another approach would be to replace Sun's JWS with something more Eclipse friendly. For example, I've suggested an Eclipse Framework install that would include all the RCP pieces and glue/registry entries so that a user could (once the framework was installed) very easily install and run an RCP application that contained only their application code. In other words, they wouldn't have to deploy copies of any org.eclipse code, and the application downloads could be as small as a few kilobytes instead of multiple megabytes. This would be similar to the way the JRE itself works, or the way that MS .NET Framework works. Ideally the Eclipse Framework install would include a Java runtime so it would be self-contained. It could also include a new .jnlp handler or something similar (.rcp anyone?).
I don't even play a JNLP expert on TV but... It seems JNLP wants to manage the jars it downloads. No surprise here. In effect they download the set of jars listed in the JNLP manifests and then put these on the classpath of a JNLP classloader and start your app. Unfortunately, Eclipse wants to create a mess of classloaders itself (one per plugin). All is not lost. Eclipse also has the much debated feature of not including the app classpath on the classpath of the plugins (i.e., the parent structure includes the system classloader, not the app classloader). So, one approach would have JNLP download all the plugins as jars, put them all on the classpath and start (a modified) main(). The fact that all the plugin jars are on the classpath is irrelevant as we will never load the classes from there. We will instead create new classloaders for the various plugins and use those to load classes. So, what's the problem? Well, JNLP wants to lay the jars down wherever it wants and there is no way for us to find out where it has put them. In their world there is never a need to do this because hey, everything is on the classpath. We looked at introspecting the classloader to discover all the jars but this info is not exposed. It may be sufficient to get a modified classloader in there that would expose the classpath entries. That would require modifying the JNLP code itself and then somehow managing to get it installed etc. Failing that, some other mechanism for discovering the downloaded plugins (AND configuration information) would be required (I believe this is Pascal's #2 in comment 18) On comment #17, Eclipse 3.0 has the ability to run plugins out of jars. That is, each plugin would be in a jar by itself. In full generality this jar can just be the jar used on update sites (see comment 19). In practice however, you really want to build a jar which has all the code directly in the root (rather than in nested jars). For an example of this, see the org.eclipse.core.runtime.tools plugins. Using this approach the plugins really are just jars in the normal Java sense that happen to have some manifest files (manifest.mf and plugin.xml) in them that help the runtime understand what to do. Currently this deployment mechanism is known to work well but its use for Eclipse itself has seen little testing. Re comment 20: Yes, deploying an Eclipse WebStart mechanism has some interesting characteristics. I lean more towards installing the absolute least amount of stuff needed (see above) rather than trying to install a common subset. The mechanism should cache appropriately so that the common pieces are only downloaded once anyway. Ultimately it would be best to get native JNLP working. If ew have to do our own mechanism that would unfortunate but should not inhibit attaining the goal of webstarting Eclipse.
When you say "JNLP wants to..." do you really mean JNLP, JWS, or Sun's implementation of both? I'm wondering how much of this behavior is unchangeable standard API and how much is changeable by a new (but possibly compatible) implementation. You say plug-ins entirely in jars is "known to work well" but has "little testing" in Eclipse. I remember this showing up on a plan item a while back but can you provide some pointers to examples, tests, articles, or doc for this? I'm wondering how running plug-ins out of jars would affect performance. Eclipse loads zillions of little files, e.g. gif images, so it might have a positive effect. It's hard to say without testing. You may also be interested in this: http://support.sas.com/rnd/appdev/Tools/applet-performance.htm
will any of the webstart enhancements in java 1.5 help make jnlp more eclipse friendly? http://java.sun.com/j2se/1.5.0/docs/guide/javaws/enhancements-1.5.0.html
When Jeff said "JNLP wants to...", he was describing the behavior observerd (and if I remember correctly specified) with two different JDKs. JDK1.5 does not provide new interesting features for what we are trying to do.
Here's a view from the corporate world... As mentioned in Comment #20, I think it is correct to say that most corporate users don't care how app management occurs. Whether updates come from JWS or UpdateManager makes no difference. All we care about is: * The ability to install the app for a user with no admin permissions using the existing JRE/JWS. * The ability to grant or deny plugins without requiring user interaction. Thus, stripping some of the "value" of JNLP is perfectly acceptable as long as Eclipse fills in the blanks. Replacing Sun's JWS with an Eclipse based JNLP engine is a long shot since it involves the cooperation of IT. With that in mind, in my current corporate environment, we have taken Martin Beuchi's first approach (Comment #5). We have a custom JNLP installer that installs eclipse and our plugins into the JWS-specified installation area. Then we have a "starter" JNLP app that simply starts that Eclipse in another process (with properties from the JNLP). After startup, Eclipse is free to work as normal. This works well since it avoids the complexities of mixing these two technologies and satisfies the two requirments mentioned above. In addition, we get some nice benefits, such as the ability to completely manage the eclipse installation directory before Eclipse starts. So we can cleanup old files, delete the configuration directory when required, or revoke access to certain plugins (by deleting them). Of course, all of this puts the work on the custom JNLP installer and starter app. Given a choice, I'd rather see the effort go into building robust versions of these two JNLP pieces and shoring up the update manager over trying to merge these two (incompatible) technologies. -Stephen
take a look at http://sourceforge.net/projects/webrcp/ source code and working example for RCP applications launched via Sun's Java Web Start.
I tried out the tutorial using Tomcat 5.5 and JDK5.0rc. It works fine aside from IE not understanding what to do with a JNLP mime type. I ran it once from the web link, used JWS to install a shortcut on my desktop, and brought it up that way again to make sure that worked. However it seems to be a little sluggish coming up. For example (this is after it's already installed) when I double-click on the icon it does this: - First it shows a splash screen (I guess from JWS) that says "RCP Tutorial/iMedic GmbH" and there is a pause of 3-7 seconds. - Then it pops up a security warning asking if I want to trust the signed application distributed by Daniel Mendler. I click Yes, but it asks me every time. I didn't want to click Always because I wasn't sure if that meant always trust this app or always trust Daniel Mendler (I'm sure he's a nice guy, but...). - Next I get a little progress monitor type dialog that says "loading tutorial- part3". This takes from 4 to 10 seconds. - Then the dialog goes away and nothing happens for 1-4 seconds. - Finally the application comes up. Total elapsed time: 8-21 seconds plus time looking at the security dialog. If I run the application outside of JWS (a locally deployed copy I made from the original source), it takes between 3 and 6 seconds before I see the application window. Which, I think, is still too long but noticably shorter than running it through JWS. I watched it run through the excellent File Monitor utility from www.sysinternals.com. Most of the time starting up the naked application comes from opening and reading squillions of pieces from ramdom locations in various jar files like rt.jar and workbench.jar in very tiny chunks. Ok, I guess there's not much we can do about that. With JWS, javaws.exe starts up and reads its dll's (it's a native app launcher I guess). Then it starts a VM, and loads lots of little chunks from its own jar files. When you hit OK on that security dialog, first all the zip files in the JNLP package are copied from somewhere into a temporary directory if that directory doesn't already exist. Then they are unzipped into another temporary directory called "unpacked" (regardless of whether or not it already existed). This copying and unzipping happens while that progress dialog is spinning. Then finally a new VM is started and the RCP application starts reading its little bits and pieces. I couldn't come up with a more inefficient way to run a program if I tried. 8-)
Hi Ed, thanks for trying out and for testing the provided code! We are wondering why you didn't post your comment in sourceforge. however, fortunately we found your comment here. Most of your comments are only related to the JWS-framework and not to the provided code. The overhead of webRCP takes only about 1-2 seconds, the rest of the time is consumed by downloading the application-archives and mostly by OSGI... > - First it shows a splash screen (I guess from JWS) that says... yeap, that's JWS by default > trust this app or always trust Daniel Mendler (I'm sure he's a nice guy, > but...). yes, we are nice guys :) we had to sign the application with a test key...you can sign your own application with any certificate you like...e.g. you can generate your own key and always trust Ed Burnette. Unfortunately, JWS requires a signed application for accessing the local filesystem and for other restricted actions. > This takes from 4 to 10 seconds...1-4 seconds..Total elapsed time: 8-21... - during the first start it downloads all the archives which contain the plugins (this will not be done a second time unless the archives change) - most of the time is consumed by eclipse, WebRCP itself takes about 1-2 seconds plus download-time: here we are working on an improvement > If I run the application outside of JWS (a locally deployed copy I made from > the original source), it takes between 3 and 6 seconds before I see the > application window. Which, I think, is still too long but noticably shorter > than running it through JWS. outside of JWS it becomes a pure RCP-Application: maybe you can provide us with some help here! > jar files like rt.jar and workbench.jar in very tiny chunks. Ok, I guess > there's not much we can do about that. no, that is all internal VM-business > When you hit OK on that security dialog, first all the zip files in > the JNLP package are copied from somewhere into a temporary directory if that > directory doesn't already exist. Then they are unzipped into another > temporary directory called "unpacked" (regardless of whether or not > it already existed). no, that should not be the case: the system just checks the files whether they are missing...but the files will not be unpacked each time. > This copying and unzipping happens while that progress dialog is spinning. > Then finally a new VM is started and the RCP application starts reading its > little bits and pieces. a new vm will not be started...it might look like it because Java often creates more than one process > I couldn't come up with a more inefficient way to run a program if I tried. 8) we tried hard to make it as efficient as possible: however, we were bound to certain limits provided by JWS. Developing our own JWS/OSGI was not the goal! Any help to make it faster/better will be appreciated. Daniel Mendler Stephan Wilczek
I looked at the SF project and didn't see any activity besides the files so I just posted here. Most or all of the problems seemed to be related to JWS anyway. I wasn't counting the download time; I had already run it once (and thus downloaded it) and installed a shortcut to the Windows desktop. I took a closer look at the file trace logs. The files in the "unpacked" directory aren't being written each time as I first thought, but they ARE being queried for existence one by one. Apparently somebody is going through the input zip file and making sure every single file in there exists in the "unpacked" directory. That takes a noticable amount of time for the short tutorial and it would take longer for real programs.
Created attachment 15494 [details] Project and code for running Eclipse from JavaWebStart This is an eclipse Java Project with code and build file and notes for running Eclipse from JavaWebStart. The basic approach is to avoid JavaWebStart as much as possible (more on that if you're interested). So, basically, this just uses JavaWebStart to install Eclipse, start the process off, and let it do its thing. There are some mechanisms for doing housekeeping and the such that bypass some of the shortcomings of JWS (no cleanup of old jars, etc.) Let me know if you've got any questions.
Created attachment 15779 [details] replaces first attachment Fixes a few minor-ish bugs in first attachment
Stephen, First off - thanks for sharing this. I picked it up from Eclipse forums. It's saved me loads of time learing all the details of custom JNLP installers. A couple of things: With regard to the plugins zip - I'm using the Export function on my plugin projects, choosing "Deployable Plugins and Fragments" in the wizard, then choosing "a single ZIP file" export option. This results in a ZIP which includes the plugin directory in the path. When I deploy this with WebStartEclipse my plugins end up in a links/plugins directory which is parallel to the eclipse root install directory. Is there something I need to configure to get the plugins to extract to the real Eclipse plugins directory? Thanks, Ron ron.pomeroy@expeditors.com
Since M6, eclipse can be started using JWS. The requirements are: - plugins must be jared (preferably with . on the classpath) - plugins must be signed
Yes, but M6 leaves some issues open. At least the startup.jar handling remains mysterious to me. In addition a couple of jnlp entries have to be done by which propably could have been generated. On Ed Burrents Blog you claimed that you had an article in work about exactly that topic. I would like to see it. Regards Georg Lenz
I've added bug 94141 for the article request.
FWIW, this is documented in our upcoming RCP book...
(In reply to comment #36) > FWIW, this is documented in our upcoming RCP book... Okay, lets phrase it this way. The export action is not finished. startup.jar is missing (were you find the main class org.eclipse.core.launcher.WebStartMain) and the necessary osgi parameter are not set. So what is exported will never ever be able to run. Will that be fixed with M7? In addition to that behaves the export wizard from the context action different than the export wizard form the File>Export.. menu, the last one has no entries for jnlp settings. Regards Georg
The goal for 3.1 was to make sure that an eclipse install could be webstarted This has been achieved. I will make sure that a proper documentation makes it into the help system for 3.1. This is being covered by bug #85029. The creation of tooling was not in the plan. What we provide is some basic help for people that are using features to structure their plugins, so they don't have to write several JNLP files by hand. What people have to do manually is: write the top level JNLP file and copy the startup.jar. This is all we could do with the help we received from the community.
(In reply to comment #38) > The goal for 3.1 was to make sure that an eclipse install could be webstarted > This has been achieved. > I will make sure that a proper documentation makes it into the help system for > 3.1. This is being covered by bug #85029. > The creation of tooling was not in the plan. What we provide is some basic help > for people that are using features to structure their plugins, so they don't > have to write several JNLP files by hand. > What people have to do manually is: write the top level JNLP file and copy the > startup.jar. > This is all we could do with the help we received from the community. Okay, Writing the top level jnlp file by hand is okay. But its not done with coping the startup.jar because its not signed. So copying and signing that jar should be done in one build step. I mean if you have gone that far assembling a web startable rcp why stop with the last step.
Georg, I (and I'm sure Pascal) agree but we are out of time. What I have done for my JNLP work was to create a feature that contains the top level jnlp file and the signed startup.jar and a root= entry in the build.properties file. It also includes the application features. Then I can just export the feature (or use releng building) and get the whole app placed on a site ready for users to run. This works and is relatively painless. A shift to being able to do anything interesting to the root files is non- trivial.
(In reply to comment #40) > Georg, I (and I'm sure Pascal) agree but we are out of time. What I have done > for my JNLP work was to create a feature that contains the top level jnlp file > and the signed startup.jar and a root= entry in the build.properties file. It > also includes the application features. Then I can just export the feature (or > use releng building) and get the whole app placed on a site ready for users to > run. This works and is relatively painless. > A shift to being able to do anything interesting to the root files is non- > trivial. Hi Jeff, yes, that works for me. but could you please comment on the issue Update Manager versus JWS update? The final conclusion on that issue discussed in this thread is not clear to me. Can I install an application via JWS and add additional features with the Update Manager? I think yes but it is not so obvious. At least I failed e.g. to install the eclipse-platform and add JDT via the update manager Hopefully your up coming book (and or an article) will comment on that. Thanks Georg
JWS and Update have a different way of managing the plugins, and they are not conflicting. JWS stores plugins in a special cache, whereas UM stores them into a site. Therefore using both is possible but any plugin installed by JWS will not be updatable by the Update Manager and vice-versa.
(In reply to comment #42) > JWS and Update have a different way of managing the plugins, and they are not > conflicting. JWS stores plugins in a special cache, whereas UM stores them into > a site. > Therefore using both is possible but any plugin installed by JWS will not be > updatable by the Update Manager and vice-versa. Hei Pascal, I think they are conficting in the following sense. Take my example: Install the plattform (plain, without JDT and PDE) with JWS. Try to add JDT with the update manager-> it will not work, the update manager will not find the required plugins-> end of update?!? May be I am missing a currently undocumented property or what so ever?!?.. Regards Georg
reopening to see if there really is a problem. Investigate for RC2
moving to runtime, otherwise we will forget about it.
I can confirm that update works from an eclipse installed and started from JNLP. However there are some restrictions: - plugins installed by JNLP can't be updated by Update and vice-versa - features are not deployed through JNLP and if they were they would not be found by update manager (bug #99039). Therefore only features that do not require features installed from JNLP can be installed, which may sound like a big restriction but is in fact not :). If you have more specific issues, please open separate bug reports.
(In reply to comment #46) > I can confirm that update works from an eclipse installed and started from JNLP. > However there are some restrictions: > - plugins installed by JNLP can't be updated by Update and vice-versa > - features are not deployed through JNLP and if they were they would not be > found by update manager (bug #99039). Therefore only features that do not > require features installed from JNLP can be installed, which may sound like a > big restriction but is in fact not :). > If you have more specific issues, please open separate bug reports. Hei Pascal, that (feature requiring feature) was not the case. That was the first thing I changed in my example: eclipse-platform (plain) via JWS, add JDT with update manager. I resolved the dependencies of the JDT feature to the plugin level. And even that dit not work?! Regards Georg
