Hi, Following up on this commit, since it highlights an issue with how we manage the lifecycle of pluggable components in Oak.
On Fri, Apr 27, 2012 at 1:50 PM, <[email protected]> wrote: > Fix initialization order issue with the query index provider. > [...] > private ContentRepositoryImpl(MicroKernel mk) { > - this(mk, new Indexer(mk)); > + this(mk, getDefaultIndexProvider(mk)); > } > > + private static QueryIndexProvider getDefaultIndexProvider(MicroKernel > mk) { > + QueryIndexProvider provider = new Indexer(mk); > + provider.init(); > + return provider; > + } > + > + /** > + * Creates an Oak repository instance based on the given, already > + * initialized components. > + * > + * @param mk underlying kernel instance > + * @param indexProvider index provider > + */ > public ContentRepositoryImpl(MicroKernel mk, QueryIndexProvider > indexProvider) { > microKernel = mk; > valueFactory = new CoreValueFactoryImpl(microKernel); > @@ -73,7 +86,6 @@ public class ContentRepositoryImpl imple > queryEngine = new QueryEngineImpl(microKernel, valueFactory, > indexProvider); > > // FIXME: workspace setup must be done elsewhere... > - indexProvider.init(); > queryEngine.init(); > NodeState root = nodeStore.getRoot(); My idea here is that any pluggable components passed to a ContentRepositoryImpl or other core class should be already initialized or be able to lazily initialize itself when needed. This way the lifecycle of a pluggable components like QueryIndexProvider are not bound to the lifecycle of the repository instance. If a pluggable component needs to be tied to a specific repository instance (for example if it needs per-repository initialization and cleanup), we should make the plugin interface a factory, that the repository instance can call to retrieve the actual per-repository component to be used within the lifecycle of that repository. BR, Jukka Zitting
