Hi all,
I have been thinking about our JCR Install tool (and had to do some
heavy-lifting in a product of ours, which uses JCR Install).
Currently JCR Install doing heavy work inside of "system" threads -
either as per OSGi Service Change Event or as per Declarative Services
activation. The drawback of this is, that JCR Install should probably
not do any heavy-lifting at these times.
Additionally, given that JCR Install is intended to be a "low level"
tool to manage bundle installations and configurations, it should also
probably have a dependency tree, which is as small as possible.
Therefore, I think, we might want to refactor JCR Install along the
following lines:
(I) Use one worker thread for all jobs
Currently JCR Install does some work in the Declarative Services thread
upon activation, installs its own thread for bundle management, uses a
framework thread upon FrameworkEvents, uses another foreign thread if
startup is initiated by binding to the JCR Repository. This is all very
uncontrolled and also works in threads, which may not be save and
heaving while holding system wide locks.
Using a single worker thread, we can:
* control the sequence of actions
* run without any system wide locks imposed upon JCR Install
(some actions will create locks, but these are below
JCR Install, not outside of JCR Install, while JCR Install
is active)
A drawback is, that actions are serialized in this thread and the thread
may block, but I don't think, this is really an issue. In addition we
might have to define an internal API for this worker thread, most simply
it may just be Runnable instances enqueued for the thread to just run.
(II) Better collect bundle management
Currently when changes are noticed in the repository, bundles are first
removed, before new bundles are installed. If now a bundle file is
replaced with a new version (bearing a new version in the file name),
the bundle is not updated but uninstalled and installed again. This is
not technically wrong, but not good either.
JCR Install should do better here and collect all changes (removal,
addition, update) and correlate them to decide on the actual work to be
done. The information for this correlation is all available, the hard
work is the task of correlation, probably.
See also SLING-895 [1] which already proposes this approach.
(III) Handling "self" and dependencies
One big issue (which is also an issue for example for the Web Console
allowing for bundle updates through the Web Console) is updates to the
JCR Install bundle itself or updates to dependencies of JCR Install,
most notably the repository API and its providers.
It is very important that state information is not lost while JCR
Install or any of its components are being deactivated due to dependency
changes. One such case of state information keeping is in the
OsgiController: the list of bundles to start.
We have seen situations, where this information has actually been lost
and not all bundles have been started after recovery.
(IV) Integrate with the Web Console
Whatever might be of interest here ....
WDYT ?
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-895
