[jira] Resolved: (SLING-1078) jcrinstall - take four

["Bertrand Delacretaz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz resolved SLING-1078.
----------------------------------------

       Resolution: Fixed
    Fix Version/s: OSGi Installer 3.0.2
                   JCR Installer 3.0.2

Marking this issue resolved, we will create more specific issues as needed

> 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 Install 2.0.4
>            Reporter: Bertrand Delacretaz
>             Fix For: JCR Installer 3.0.2, OSGi Installer 3.0.2
>
>
> 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.