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
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.
