Proposal for configuring Oak using PojoSR and not miss good old repository.xml for configuration!

[Chetan Mehrotra <ch...@gmail.com>]

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

Re: Proposal for configuring Oak using PojoSR and not miss good old repository.xml for configuration!

[Tobias Bocanegra <tr...@apache.org>]

Hi,

On Thu, Mar 6, 2014 at 9:13 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> 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.
I don't think we should do that, and stick to the default properties
files that felix generates. they are easy to understand and are
modular. for example, adding a new bundle + config  can be provisioned
with a zip-file. but if you have 1 XML, you need to merge configs.
(that, and beside the fact, that I dislike XML very much).

> 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?

+1 That would be very cool.

regards, toby

>
> 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