openInstaller: Bootstrap Over Http using JNLP
Project Description: Enable openInstaller-based installers to be executed from a website. The install should download a small bootstrap that gets the process going. At some point the openInstaller engine should take over and continue to access its required components from the site.
Use Cases: UC-001 1. User goes to URL. 2. Click Download and Install Product via http(s). 3. Product installer bootstrap is downloaded to the system and invoked. 4. User is presented with the install sequence. UC-002 1. User goes to URL. 2. Click Download and Install product from local. 3. Product install image is downloaded in archived format. 4. User extracts image to known location. 5. User starts install and is presented with the install sequence.
Requirements:
- Both types of install, web or image based, should be similar in experience as well as layout of product.
- Initial bootstrap should be small (we should decide how small as a goal).
- Only 1 jnlp script is preferable.
- Tools will be needed to enable the creation of the server side.
- Security is needed. Webstart supports security through signed JAR files.
- Native packages on solaris must be streamed for web based distro.
- Streams for RPMs required?
Findings / Issues:
- All the resources required by the JNLP application (our installer) should be in the form of JARs.
- All JARs should be signed by the same certifying authority.
- The "File" API is being used extensively by the current openInstaller code. Since most of the File-related code won't work in a HTTP context, a new layer of abstraction needs to be introduced in the code that resides over the existing File-based layer. This new layer would be responsible for handling URL-based logic for initializing the service providers.
- All classes loaded using Java's reflection mechanism would have to be loaded using the same ClassLoader object, which is the default one.
- Migrating to JDK 1.6 would considerably reduce the bootstrap size since JAXB jars (which constitute a big part of the resources) wouldn't need to be explicitly included as part of the bootstrap.
Solution: The solution to the problem would consist of doing the following... 1. A single JNLP (.jnlp) file would be used for any product's installer and this file would have to be dynamically built during the build process. We could initially start off with a jnlp template containing dollar-substitutable variables and the actual substitution could take place during the build process. 2. The main class (entry point) for the JNLP-based installer would be a new class (say, HTTPBootstrap), which is similar to EngineBootstrap, but has implementation specific to a HTTP context. Similarly, HTTPOrchestrator would be called next instead of Orchestrator. 3. The JNLP file would be required to implement all the logic that's implemented by the engine-wrapper script, i.e., setting of all the required environment variables like classpaths, system properties etc. 4. The individual service providers need to introduce the abstraction described above (see bullet 3 of "Findings / Issues") to successfully initialize themselves in Webstart mode. 5. Once all the above steps are done & the installer window pops up, not much changes to the code would be required thereafter.
Project Status This feature is available in openInstaller since 0.9.4. For more information on this feature, please see the details of the bug 6441929 at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6441929 For information on how to use this feature, please see the detailed instructions at http://blogs.oracle.com/JayzSpeak/entry/openinstaller_feature_overview_installation_over
|