Hi,
> In case of cluster db journal, the hostname of db connection.
The hostname of the database (if a database is used) and the database
name needs to be known when creating the repository object. Storing it
in a 'repository.xml' file is possible, but it's just an unnecessary
indirection. If you keep this information in the repository.xml file,
where do you store the path of the repository.xml file? If the user
name and password need to be protected (not stored as plain text) how
do you do that? Using yet another indirection (JNDI)?
I suggest to pass the database URL (or whatever storage you use) when
creating the repository object. Example (using a helper method; just
an example): RepositoryFactoryImpl.openRepository("jdbc:postgresql:repo",
"user", "password");
If you want to use a repository.xml file (that only contains the
database connection information) you can of course. But do you really
need an XML file for the database URL, the user name, and the
password? Specially if the user name and password are things that
normally should not be stored in a file?
Speaking about databases: do you know of a database where you need to
store the location of the database files in an XML file? I guess there
are some databases where you *can* do that, but I don't know any where
you *have to*.
>>> Configuration should be editable without boot the repository.
>> Why?
> Again, for db store, if db host changes after repository shutdown, we
> should be able to config the repository to use a different db host.
> Like we can change in current repository.xml.
The current repository.xml file contains much more than just the
database connection settings. It contains the search index
configuration (or at least part of it), file system configuration,
cluster configuration, data store configuration, security
configuration, workspace configuration (for some the version store),
etc. All that, except for the database connection settings, can be
stored in the repository itself. Because it simplifies things.
> It's a feature of some application server to manage cluster configurations.
I don't see a problem here. They can.
> I would prefer leave the complicity out of default standalone deployment.
I like to keep things as simple as possible. The repository.xml and
workspace.xml files are not required; they actually make things more
complicated than necessary (specially, but not only, when clustering
is used).
Regards,
Thomas
