[
https://issues.apache.org/jira/browse/SLING-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-1078.
-----------------------------------
> jcrinstall - take four
> ----------------------
>
> Key: SLING-1078
> URL: https://issues.apache.org/jira/browse/SLING-1078
> Project: Sling
> Issue Type: Improvement
> Components: Installer
> Affects Versions: JCR Installer 3.0.0
> Reporter: Bertrand Delacretaz
> Fix For: Installer Core 3.0.0, JCR Installer 3.0.0
>
>
> 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?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
