Hi, Till JR2 the repository was configured via repository.xml which served two purposes
1. Support for DI 2. Configuring the service properties >From the end user perspective this used to prove useful from usability point of view. 1. One can see what all components are involved 2. Easy to specify all config properties at one place. The xml can be documented also 3. JR2 used to warn if property names are not correct. So good support for handling misconfiguration >From developer perspective the repository.xml constrained us in the ways repository element can be configured. With Oak we have done away with the repository.xml approach. The repository components can now be assembled programatically. In OSGi repository configures itself through std OSGi constructs. For non OSGi case well we have the Jcr class which provides a ready repository with suitable defaults. However configuring properties still involves quite a work and so far have to do it in code IMHO having configuration in place xml/yaml etc is pretty useful to a end user and simplifies administration. Proposal ------------- To enable ease of both configuration and modularity we already support OSGi. With PojoSR (as explained in other mail [1]) we can support both 1. Have a PojoSR based RepositoryFactory to provide access to Repository instance 2. Have a custom xml way to capture OSGi configuration. Instead of config scattered across multiple property file we can consolidate all such config in a single file. For some example see [2] [3] As implemented with [4] when repository starts with default Segment store configured it creates following directory layout <repo-home> |__ /bundles |__/content |__/config the config folder can be replaced with single xml. Bundles folder is created by PojoSR as some bundles like ConfigAdmin use the bundle data folder to store some state Benefits 1. Repository can easily be extended vis std OSGi constructs is users use DS and put there "bundle" in the flat classpath 2. For simple setup users can directly register there service programatically with the PojoServiceRegistry 3. Configuration is managed in a central place and can easily be edited 4. For more adventurous usage users can also enable the Felix WebConsole when deploying a Oak based application in Tomocat or even uses Felix Jetty bundle!. Most of the webconsole would work Thoughts? Chetan Mehrotra PS: PojoSR is now being moved to Apache Felix (FELIX-4445) [1] http://markmail.org/thread/2vnktbuq2jd2ovs5 [2] https://docs.jboss.org/author/display/AS7/OSGi+subsystem+configuration#OSGisubsystemconfiguration-cas [3] https://access.redhat.com/site/documentation/en-US/JBoss_Fuse/6.0/html/Deploying_into_the_Container/files/DeployCamel-OsgiConfigProps.html [4] https://github.com/chetanmeh/oak-pojosr
