There is already an OSGi specification - the deployment admin
specification - which allows you to package a set of bundles together
with configuration. Without going into details, I think it already
covers most of your stuff ootb.
In combination with the jcrinstall I think you get everything for free.
Carsten
Bertrand Delacretaz wrote:
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
--
Carsten Ziegeler
[EMAIL PROTECTED]
