Version 12 (modified by gogov, 16 years ago) (diff) |
---|
Analysis
Overview
JWS is broken, incomplete and outdated. Fix it.
Task requirements
- http://asteasolutions.net/~jordan/ exists no more. JWS demo lived there, now it's gone. Put it somewhere on sophie2.org and fix it.
- Before, http://sophie2.org/jws has been used for the above. It's also broken and outdated. Fix it.
- currently, a JWS launch configuration exists only for the Author application. Create such also for Reader.
- update content of this dir - launchers, jars, etc..
- identify and fix other related settings.
- Fix org.sophie2.launcher.JavaWebStartMain if needed.
Task result
- Nice and tidy place on sophie2.org with all JWS related files.
- Working Author and Reader jnlps.
Implementation idea
- Go through the mentioned locations, locate and fix any errors and/or update any outdated code.
Related
How to demo
- Successfully run Author and Reader through JWS.
Design
- I'll use http://sophie.org/jws to store the following:
- keystore
- all needed jars
- config files
- jnlps
- readme
- ...
- I'll create a new keystore with keytool and put it in http://sophie2.org/jws
- it will be still non-official though we should create an official one at a given point. We're not Al-Kaida, we're Astea for Meddle's sake!! We should have our official keystore!!
- I'll sign all jars which need to be signed with jarsigner
- I'll refactor JavaWebStartMain class to System.setProperty("editor", ...) to whatever is actually run, either "author", "reader" or "server". JavaWebStartMain.main will receive this as a 3rd parameter from the jnlps.
There are some new issues which need to be fixed:
- FileEntryManager.getRoRoots() currently searches for a "modules" dir from the current working directory to the root of the filesystem tree which is not cool because with JWS no such directory exists and the initial current working directory can be unpredictable. FileEntryManager needs this dir to find all .jars which correspond to Sophie modules and be able to look up inside them for resources, such as icons etc. In order to fix it, FileEntryManager will access the new ListProp<ModuleInfo>startedModules() of the running ModuleRegistry.
- Both FakeModuleRegistry and TrueModuleRegistry will need to implement ListProp<ModuleInfo>startedModules():
- TrueModuleRegistry will implement it by getting a BundleContext and use it to get all the started Bundles and their URLs (in the case that a given URL is a local file path, it will be converted to absolute file path). Then it will create respective ModuleInfos and fill startedModules() with them.
- FakeModuleRegistry will implement it by parsing the System.getProperty("java.class.path"), filter out "org.sophie2.<module-name>/target/*" entries and constructing URLs to the jars inside these locations, then respectively construct ModuleInfos and fill startedModules() with them.
- The above mentioned BundleContext will be gotten from a newly created CoreModularityModule. As specified by the docs, a created BundleContext is passed to the start() and stop() methods of a Bundle, so that's where well save this BundleContext and expose it for public usage. This is ugly and according to the docs, a BundleContext instance is responsible only for the Bundle it's associated with, though we can access all started Bundles through any given BundleContext produced by the same Felix instance, so we'll exploit this "feature" and siut it for our needs (:
These modifications will fix the above mentioned problem with the FileEntryManager, so JWS will be implementable, and also they'll be synchronized with Pav's new modifications so no new refactoring is expected to be done to accomplish this task.
Implementation
(Describe and link the implementation results here (from the wiki or the repository).)
Testing
(Place the testing results here.)
Comments
http://www-ab.informatik.uni-tuebingen.de/software/crosslink/doc/WebStartGuide.pdf, page 11 shows how to turn on a separate Java Console window. Useful for debugging when starting javaws from the terminal doesn't provide output.