[
https://issues.apache.org/jira/browse/SLING-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-646:
-----------------------------------
Component/s: (was: OSGi)
JCR Install
> jcrinstall - take two
> ---------------------
>
> Key: SLING-646
> URL: https://issues.apache.org/jira/browse/SLING-646
> Project: Sling
> Issue Type: New Feature
> Components: JCR Install
> 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.
