Hi, On Tue, Mar 4, 2014 at 3:11 AM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > 1. Configure components - Currently various sub modules are using > different ways to configure. Some is being done via system properties, > Security module has its own way of configuring, DataStore support has > its own
That's why I brought up the new DataStore config mechanism as somewhat troublesome. Security configuration has the same problem. System properties are currently used in places where a quick and simple way is needed to tweak options during testing. If a particular setting needs to be available in production, it should be made configurable through a setter or a constructor argument. Then it is easy to control the setting through OSGi service properties or by whichever framework or configuration mechanism is being used. > 2. Expose extension points - Exposing extension points in non OSGi env > becomes tricky. We faced some issues around LoginModule extensiblity > earlier We have plenty of extension points (CommitHook, QueryIndexProvider, etc.) that work just fine. The problem with LoginModules is caused by the tricky way JAAS works, not by any inherent flaw in our extension mechanism. > PojoSR [1] provides support for using OSGi constructs outside of OSGi > framework > > I have implemented a POC [2] which makes use of PojoSR to configure > Oak in pojo env. So far basic stuff seems to work as expected. > > Would be worthwhile to investigate further here and possibly provide a > PojoSR based RespositoryFactory? Looks nice! Having alternative ways of configuring and running Oak is useful, as it helps us spot problems like the one you brought up about the security configuration. BR, Jukka Zitting
