Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
JCR Installer 3.0.0
-
None
Description
After splitting the jcrinstall code for SLING-904, we have reviewed it with Felix and Carsten, and come to the conclusion that moving more logic to the osgi.installer module will help.
Here are (rough) notes from our review session, on which I'll base the next (and hopefully last 
rewrite of jcrinstall.
= Redesign =
OSGi controller keeps track of all supplied resources, with states: installed, ignored, etc. It stores RegisteredResource objects which are derived from InstallableData.
At startup, jcrinstall client informs osgi.installer of all installable resources which are present. Installer can then detect which resources are gone since last startup ("rendez-vous").
OsgiController rendezvous method: client provides list of existing InstallableData, URL scheme ("jcrinstall://")
OsgiController methods: resourceUpdated(InstallableData), resourceDeleted(InstallableData). Or maybe register/unregister resource.
Use a Comparator to decide on bundle priorities: higher versions over lower versions, take into account the Maven -SNAPSHOT convention, and let clients provide a priority value as part of the InstallableData. Jcrinstall uses that priority to give precedence to bundles found in /apps over those found in /libs.
jcrinstall must call rendez-vous if a watched folder is deleted - test what happens if for example parent folder (/apps) is deleted.
Those /apps and /libs path come from the ResourceResolver search path, not hardcoded anymore.
InstallableData methods: getURL, getDigest, getPriority + data access.
InstallableData becomes a RegisteredResource inside the osgi.installer - do not hang on to InstallableData instances, to avoid problems if jcrinstall module goes away.
OSGi console displays list of RegisteredResource objects, using a Servlet as the plugin to minimize coupling with webconsole.
OsgiController admin APIs: executeScheduledOperations, getRegisteredResources (uninstall method?)
Use a real worker thread.
Handle resource priorities right before creating OSGi tasks, and remove the ones who are overridden by priority - installer walks the list of RegisteredResources, and creates OSGi tasks (install/uninstall/update etc.) based on that list.
RegisteredResource has two state fields: desired and actual, and by comparing them we create OSGi tasks.
The list of RegisteredResource is ordered by priority, to compute overrides, and grouped by "OSGi entity": which bundle or config the resource maps to. RegisteredResource.getEntityId() returns bundle ID, config PID, etc
Modules structure: installer/osgi, installer/jcr, installer/jcr/testing
= Code cleanup =
Can we remove JcrInstallService? only used for testing
NodeConverter can be in implementation package
RunMode in ConfigNodeConverter should be removed - use folders only for override, to avoid confusion.
Merge PropertiesUtil with its single user classRepositoryObserver: propertiesUtil.loadProperties(serviceDataFile) not needed anymore, if OSGi controller keeps the list of all registered resources
Delay RepositoryObserver startup to make non-first startups faster?
WatchedFolder scanning might be simplified
Subclasses: DictionaryInstallableData, FileInstallableData
InstallResultCode should go
JcrInstallException should go
OsgiControllerServices is implementation
OsgiResourceProcessor can be removed
MissingServiceException: unused?
EventsCounterImpl -> make Activator the listener, and increment a static long volatile counter
DictionaryReader -> move to tasks package?
MissingServiceException can go?
OsgiControllerTaskContext is not needed, pass OsgiControllerImpl?
Attachments
Attachments
Issue Links
- is related to
-
-
- Resolved
-