Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1412

[Patch] Java-based test configuration of Jackrabbit (no repository.xml needed)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: config, jackrabbit-core, test
    • Labels:
      None

      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.

        Issue Links

          Activity

          Hide
          Alexander Klimetschek added a comment - - 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");

          Show
          Alexander Klimetschek added a comment - - 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");
          Hide
          Alexander Klimetschek added a comment -

          Same patch as before, but fixed a variable replacement bug.

          Show
          Alexander Klimetschek added a comment - Same patch as before, but fixed a variable replacement bug.
          Hide
          Jukka Zitting added a comment -

          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?

          Show
          Jukka Zitting added a comment - 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?
          Hide
          Alexander Klimetschek added a comment -

          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.

          Show
          Alexander Klimetschek added a comment - 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 .
          Hide
          Jukka Zitting added a comment -

          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.

          Show
          Jukka Zitting added a comment - 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.
          Hide
          Alexander Klimetschek added a comment -

          You are right. I plan to provide a patch for the trunk that modifies the config classes directly, after the work on 1.3.4 is done.

          Show
          Alexander Klimetschek added a comment - You are right. I plan to provide a patch for the trunk that modifies the config classes directly, after the work on 1.3.4 is done.
          Hide
          Jukka Zitting added a comment -

          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.

          Show
          Jukka Zitting added a comment - 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.
          Hide
          Jukka Zitting added a comment -

          Postponing to 1.6

          Show
          Jukka Zitting added a comment - Postponing to 1.6

            People

            • Assignee:
              Jukka Zitting
              Reporter:
              Alexander Klimetschek
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development