[jira] Issue Comment Edited: (JCR-1412) [Patch] Pure Java-based configuration of Jackrabbit (no repository.xml needed)

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571458#action_12571458 ] 

alexander.klimetschek edited comment on JCR-1412 at 2/22/08 8:54 AM:
---------------------------------------------------------------------

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");


      was (Author: alexander.klimetschek):
    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-940). 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");

  
> [Patch] Pure Java-based configuration of Jackrabbit (no repository.xml needed)
> ------------------------------------------------------------------------------
>
>                 Key: JCR-1412
>                 URL: https://issues.apache.org/jira/browse/JCR-1412
>             Project: Jackrabbit
>          Issue Type: New Feature
>          Components: config, jackrabbit-core, test
>            Reporter: Alexander Klimetschek
>             Fix For: 1.3.4
>
>         Attachments: jackrabbit-core.dynamic-config-for-testing.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.