[jira] Assigned: (SLING-646) jcrinstall - take two

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

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

Bertrand Delacretaz reassigned SLING-646:
-----------------------------------------

    Assignee: Bertrand Delacretaz

> jcrinstall - take two
> ---------------------
>
>                 Key: SLING-646
>                 URL: https://issues.apache.org/jira/browse/SLING-646
>             Project: Sling
>          Issue Type: New Feature
>          Components: OSGi
>            Reporter: Bertrand Delacretaz
>            Assignee: Bertrand Delacretaz
>
> Based on the jcrinstall [1] and jcrbundles [2][SLiNG-587] experiments, and after playing a bit with these modules and talking to (our) Felix, I'll start re-implementing the jcrinstall module under sling/extensions/jcrinstall, based on a mix of both codebases (jcrbundles was based on the existing jcrinstall anyway, so it's a mix already).
> Here's a quick specification.
> The jcrinstall module looks for OSGi resources (bundles in jar files, configurations in text (.cfg) files, deployment packages in .dp files) under a configurable set of paths in the repository.
> Those resources are "installed" in the OSGi framework when detected: bundles, deployment packages and configurations are installed, updated or removed as needed.
> The jcrinstall module is considered as another "user interface" to the OSGi framework, besides the existing OSGi console, and as such aims to play well with the console, and avoid any inconsistencies when both user interfaces are used. That's only a best effort, though, as we'll probably find edge cases when using both can cause problems.
> The module is split in two components:
> = OSGi controller component =
> Receives notifications of new, updated or deleted OSGi resources from the JCR observation component.
> Does not use any JCR interfaces, so as to be reusable independently.
> Manages the required queues and retries to ensure that received bundles, configurations and deployment packages are eventually activated, even if their dependencies are made available later.
> Provides permanent storage (based on BundleContext.getDataFile()) for the JCR component to store Properties for the resources that it detects.
> Uses handlers based on a common interface for the various types of resources (bundles, configs, deployment packages).
> = JCR observation component =
> Observes a number of folders in the JCR repository, based on configurable regular expressions for their paths. The default regexp causes folders named "install" to be observed.
> Limited to a configurable list of root paths, by default /libs and /apps.
> Detects added or modified files in those folders and notifies the OSGi controller of these events, providing the file's InputStream with the event, along with an event type.
> Uses the permanent storage provided by the OSGi controller to store information that allows for detecting updates and deletes of OSGi resources.
> = coda =
> Splitting the module in two well-separated components should also help automated testing - as described above, both components should be readily testable without requiring complicated setups.
> [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall/
> [2] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrbundles/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.