On Fri, Oct 19, 2012 at 8:55 PM, Jukka Zitting <[email protected]> wrote: > Note that this mechanism is mostly intended for embedded use. > Deployments in OSGi and other managed environments should use the > native construction/configuration mechanism of the environment.
I was trying to modify the Oak usage in OSGi environment to match the settings similar to what is done in default o.a.j.oak.jcr.Jcr class. To achieve the compatibility I need to resolve couple of issues 1. Lucene and OSGi - To enable Lucene related logic some steps are required (A) Wrap up the Lucene jars as OSGi bundle - The current released versions of Lucene 4.0.0 are not OSGi bundles. Some discussion around it happened in LUCENE-3167 but looks like it did not got resolved. So should we create our own wrapper bundle in Oak for now? (B) Registration of Lucene related components - LuceneReindexHook,LuceneHook and LuceneIndexProvider with OSGi SR such that they can be picked up by the o.a.j.oak.osgi.Activator and registered with the ContentRepository being constructed. We can have a single Lucene component which uses OSGi configuration to configure Lucene related logic (for now its only the homePath) and registers the respective components in SR 2. Commit Hooks - Should we add a tracker for CommitHooks similar to the way we have ones for ValidatorProvider and IndexProviders. Or for now we can just update the list present in the o.a.j.oak.osgi.Activator to match the list and order we have in o.a.j.oak.jcr.Jcr 3. SecurityProvider - Need to register SecurityProviderImpl backed by OSGi configuration with SR. Would it be fine now to add osgi related changes Chetan Mehrotra
