Details

Description

Jackrabbit should be dynamically configurable, ie. without the need for a repository.xml but through pure Java code.

This is helpful for unit tests, where you want to automatically test different configurations (eg. PersistenceManagers) without creating hundreds of repository.xml files that differ only in certain parts.

The reason for using the 1.3 branch is because I write unit tests for some backports (eg. JCR-1400). This model can be easily be put into trunk and/or 1.4 while considering to add the new configuration elements of 1.4 (eg. DataStore).

This patch does not touch any of the o.a.j.core.config classes but works "around" them by re-creating the config classes (eg. RepositoryConfig, PersistenceManagerConfig). These

are similar named, omitting the "-ig" ending, eg. RepositoryConf instead of RepositoryConfig

are located in the test code under src/test/java/org/apache/jackrabbit/test/config

provide getter and setters (the o.a.j.core.config classes don't have setters, they only have all-field initializing constructors, intended to be used only by the xml parser in RepositoryConfigParser)

can be read from repository.xml and written to it

and finally can be converted to the built-in config classes via RepositoryConf.createConfig()

The important variable replacement (eg. $

{rep.home}) is only done when converting from *Conf to *Config: RepositoryConf.createConfig() takes the properties as an argument. That way the *Conf object model is an exact copy of the repository.xml and allows a full roundtrip between XML file and object model.

All *Conf classes have a default constructor that will initialize the objects with the standard example repository.xml config. That way one can start with the basic model and only has to change certain elements, eg. typically the persistencemanagers and file systems.

For the use in test cases there is a DynamicRepositoryHelper class that extends from RepositoryHelper and is thus suited for AbstractJCRTest. An example for a jackrabbit unit test (extending AbstractJCRTest) that sets up a config for a derby bundle persistence manager that connects to a remote derby server:

Alexander Klimetschek
added a comment - 22/Feb/08 16:53 - edited A proof-of-concept for the 1.3 branch.
The reason for using the 1.3 branch is because I write unit tests for some backports (eg. JCR-1400 ). This model can be easily be put into trunk and/or 1.4 while considering to add the new configuration elements of 1.4 (eg. DataStore).
This patch does not touch any of the o.a.j.core.config classes but works "around" them by re-creating the config classes (eg. RepositoryConfig, PersistenceManagerConfig). These
are similar named, omitting the "-ig" ending, eg. RepositoryConf instead of RepositoryConfig
are located in the test code under src/test/java/org/apache/jackrabbit/test/config
provide getter and setters (the o.a.j.core.config classes don't have setters, they only have all-field initializing constructors, intended to be used only by the xml parser in RepositoryConfigParser)
can be read from repository.xml and written to it
and finally can be converted to the built-in config classes via RepositoryConf.createConfig()
The important variable replacement (eg. $
{rep.home}) is only done when converting from *Conf to *Config: RepositoryConf.createConfig() takes the properties as an argument. That way the *Conf object model is an exact copy of the repository.xml and allows a full roundtrip between XML file and object model.
All *Conf classes have a default constructor that will initialize the objects with the standard example repository.xml config. That way one can start with the basic model and only has to change certain elements, eg. typically the persistencemanagers and file systems.
For the use in test cases there is a DynamicRepositoryHelper class that extends from RepositoryHelper and is thus suited for AbstractJCRTest. An example for a jackrabbit unit test (extending AbstractJCRTest) that sets up a config for a derby bundle persistence manager that connects to a remote derby server:
// creates default config based on example repository.xml
// (embedded Derby PM, LocalFS)
RepositoryConf conf = new RepositoryConf();
// set jdbc urls on PMs for external derby
// workspaces
PersistenceManagerConf pmc = conf.getWorkspaceConfTemplate().getPersistenceManagerConf();
pmc.setParameter("url", "jdbc:derby://localhost/${wsp.home}/version/db/itemState;create=true");
pmc.setParameter("driver", "org.apache.derby.jdbc.ClientDriver");
pmc.setParameter("user", "cloud");
pmc.setParameter("password", "scape");
// versioning
pmc = conf.getVersioningConf().getPersistenceManagerConf();
pmc.setParameter("url", "jdbc:derby://localhost/${rep.home}
/db/itemState;create=true");
pmc.setParameter("driver", "org.apache.derby.jdbc.ClientDriver");
pmc.setParameter("user", "cloud");
pmc.setParameter("password", "scape");
helper = new DynamicRepositoryHelper(conf, "target/repository");

Instead of adding builder classes I'd rather just modify the Config classes directly.

Also, I'm a bit reluctant to add such a large volume of stuff in a maintenance branch. Is this required for JCR-1400 or could you live without it? Couldn't you just create custom repository.xml files for each test case that needs custom configuration?

Jukka Zitting
added a comment - 25/Feb/08 19:28 Instead of adding builder classes I'd rather just modify the Config classes directly.
Also, I'm a bit reluctant to add such a large volume of stuff in a maintenance branch. Is this required for JCR-1400 or could you live without it? Couldn't you just create custom repository.xml files for each test case that needs custom configuration?

Alexander Klimetschek
added a comment - 25/Feb/08 19:34 Yes, for a final new feature applied to the trunk I would modify the Config classes directly.
My intention was to not modify core code in a maintenance branch and work around to add it to the test code instead. That large volume only affects the test cases.
I could have done it with repository.xml files, but I wanted to do a proof of concept for a dynamic configuration, something I was missing for Jackrabbit independent from JCR-1400 .

ACK. I update the title to better reflect that this is a test-only feature for now.

I'm OK with having this in 1.3.4 since it's a special release anyhow, but generally we should avoid introducing extra features in maintenance branches, especially if a similar feature doesn't already exist in trunk.

Jukka Zitting
added a comment - 25/Feb/08 19:40 ACK. I update the title to better reflect that this is a test-only feature for now.
I'm OK with having this in 1.3.4 since it's a special release anyhow, but generally we should avoid introducing extra features in maintenance branches, especially if a similar feature doesn't already exist in trunk.

I committed the patch as-is (plus a license header for Xml.java) to the 1.3 branch in revision 631382, but let's treat that commit as a part of JCR-1400/JCR-1419 and reserve this issue for having this feature in Jackrabbit trunk.

Jukka Zitting
added a comment - 26/Feb/08 21:19 I committed the patch as-is (plus a license header for Xml.java) to the 1.3 branch in revision 631382, but let's treat that commit as a part of JCR-1400 / JCR-1419 and reserve this issue for having this feature in Jackrabbit trunk.