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