Changes between Version 11 and Version 12 of PLATFORM_DEPLOYMENT_TARGET_JWS_R1

Timestamp:

06/04/09 19:48:22 (16 years ago)

Author:

gogov

Comment:

--

PLATFORM_DEPLOYMENT_TARGET_JWS_R1

@@ -41 +41 @@
  * 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 lots of new issues with the FileEntryManager 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
+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 =