Hi, Here's a tentative spec for a service that allows OSGi bundles to be loaded by simply copying them, and their configurations, into the Sling JCR repository. I'm planning to work on this this week, based on the existing jcrinstall prototype.
The goal is to allow "application-level" bundles (like the webloader service bundle for example), to be installed and configured by copying them and their configs to the repository, usually next to the scripts that use them. This will allow Sling applications to be packaged as repository data dumps (an XML sysview should do), including the required java code bundles and initial service configurations. The implementation is based on Felix's jcrinstall prototype, http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall/ , which itself derives from the Apache Felix File Install module, http://felix.apache.org/site/apache-felix-file-install.html ** OSGI bundles management OSGi bundle jar files found in the JCR repository under /libs or /apps (default values - the ordered set of paths is configurable), inside folders named "bundles", are installed automatically, as if they had been added via the OSGi console. Removing a bundle jar file uninstalls the bundle, and modifying it updates the bundle. We might need to store digests (md5 or sha1) of the bundle jars to reliably detect modifications. All install/remove/update operations are logged at the INFO level. If several bundles with the same name are found in several "bundles" folders, only the first one found is installed, a warning message is logged for all others. The "bundles" folders must have the nt:hierarchyNode node type. ** OSGi configurations management Inside the "bundles" folders, nodes having names ending with ".cfg" are assumed to be OSGi configurations. Such nodes can either be files in java Properties format, or leaf nodes with properties which are used to initialize a Properties object. Files are easier to edit when working via WebDAV, whereas nodes with properties are easier to manage using Sling. Adding, removing or updating a configuration node causes the corresponding OSGi configuration to be added, removed or updated. All install/remove/update operations are logged at the INFO level. The names of the configuration nodes are used to build the names of the OSGi configurations, using the same conventions as the Felix File Install service (http://felix.apache.org/site/apache-felix-file-install.html). So, in some cases, several configurations will be present for one bundle, to create several instances of the corresponding service, when the bundle provides a factory. ** Configuration info servlet A Sling servlet mapped to the ".cfginfo" selector is used to provide configuration information. Addressing a bundle resource such as /apps/foo/bundles/mybundle.jar.cfginfo.json, for example, produces a json rendering of the bundle's configuration parameters, including the same info as on the OSGi console configuration page: name, localized label, localized description, type and default value of each configuration parameter. Addressing a configuration resource such as /apps/foo/bundles/mybundle.cfg.cfginfo.json produces similar output, with the current configuration values and relevant service state information added to it. ** Observing the repository for changes The subtrees of the "bundles" nodes found under /libs and /apps (*) are observed by the JcrBundlesManager. Once a data change is detected in once of these folders, the folder path is added to a queue to be processed after an update timer expires (duration is configurable), and the timer is reset by any change inside the same folder. This helps avoid problems when a bundle file is uploaded, for example, resulting in several irrelevant change events that represent the transient state of the upload process. Once the update timer expires, the bundles folder is scanned for bundle and config nodes, the OSGi framework state is compared to the information that these nodes provide, and bundles and configs are installed/removed/updated accordingly. If might be useful to only update OSGi Configurations if the new config is actually different, to avoid extraneous change events and bundle restarts. When the JcrBundlesManager service starts, the "bundles" folders inside the configured roots are scanned (asynchronously), and processed as if a change event had happened in each of them, but without waiting for the update timer to expire. ** Bundles and configs node names Only bundle and configuration nodes having names that match a configurable regular expression are considered, to avoid problems with temporary files created by editors or by WebDAV. The default regexp is "[a-zA-Z0-9].*\.[jar|cfg]$" - o - That's it for now. I'll create a JIRA issue and work in the whiteboard for now. Comments are welcome, of course! -Bertrand
