On Tue, Jul 29, 2008 at 10:08 PM, Tobias Bocanegra
<[EMAIL PROTECTED]> wrote:
> On 7/29/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
>>... I'm also being more conservative than jcrinstall in the use of JCR
>>  observation to detect changes, trying to make the service more robust
>>  when it comes to synchronising the OSGi bundles/configs state with
>>  what's in the repository after a system restart (including deletion of
>>  the sling workdir) for example...

> ...does this mean you can't drop in a bundle during runtime and have it
> automatically installed and started? imo that would be a required
> feature....

You can do that, no problem.

What I mean is that where jcrinstall used only JCR observation to
detect changes to jars and configuration files, jcrbundles can scan a
"bundles" folder and detect all changes even if it was not active when
JCR observation events were produced. That might be useful in
backup/restore or clustering scenarios, I assume.

To simplify the implementation, it uses this mechanism all the time: a
"bundles" folders is fully rescanned after any observation event is
produced inside it (after waiting 1000 msec since the last event, to
keep the system load down), and its relevant contents compared to the
OSGi state, to bring that state in sync with the bundles folder.

-Bertrand

Reply via email to