Patch looks fine to me. Probably we can collapse QueryIndexProvider and QueryEngineSettings into a single QueryEngineContext and pass that along till Root.
> So: is it worth it to have the 100 KB source code overhead just to make > things configurable separately for each Oak instance? I think there are couple of benefits * Isolation between multiple oak instance running on same jvm (minor) * It opens up possibility to have session specific settings. So later we require say JR2 compatible behaviour case for some session then those settings can be overlayed with session attributes * it allows to change the setting at runtime via gui as some of these settings would not require repository restart and can effect the next query that gets executed. That would be a major win So this effort now would enable incremental improvements in QueryEngine in future! > The Whiteboard is per Oak instance, right? For OSGi case yes Chetan Mehrotra On Wed, Mar 26, 2014 at 2:23 PM, Thomas Mueller <muel...@adobe.com> wrote: > Hi, > > I'm trying to make some query settings (limits on the number of nodes read) > configurable via OSGi. So far, I have a patch of about 100 KB, and this is > just wiring together the components (no OSGi / Whiteboard so far). > > I wonder, is there an easier way to do it? With system properties, it's just > a few lines of code. The disadvantage is that all Oak instances in the same > JVM use the same settings, but with OSGi configuration I guess in reality > it's not much different. So: is it worth it to have the 100 KB source code > overhead just to make things configurable separately for each Oak instance? > If not, how could it be implemented? The Whiteboard is per Oak instance, > right? > > Regards, > Thomas > >
