directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: One moe thing about the DS paths
Date Thu, 28 Oct 2010 07:55:06 GMT
On 10/28/10, Pierre-Arnaud Marcelot <> wrote:
> Hi Emmanuel,
> On 28 oct. 2010, at 02:39, Emmanuel Lecharny wrote:
>> Hi again,
>> currently, the default working directory for DS is server-work, not
>> partitions, as defined in the InstanceLayout.
>> I'm all for using partitions, I find it way easier to remember, and on
>> line with the current configuration.
>> That raises some question, too :
>> - should we declare the getter and setter for the log/conf/run/partitions
>> paths in DirectoryService ?
> -1, I think we should pass an InstanceLayout object instead and that object
> could be shared between configuration objects.
I agree with Pierre-Arnaud, let us not tie the InstanceLayout to DS,
it is just a kind of semantic we follow or set for making
installations follow a standard path
otherwise all that we need to start a DS is just a plain path to a folder.
>> - the log directory and partitions directory *must* be configurable : on
>> Linux, they are likely to be move to /var/log and /var/run. How do we
>> handle that ?
> I'm not sure, I handled that correctly in the Linux installers (has to be
> checked).
> AFAIR, it's possible to override the default ([InstallationLayout]/log] path
> with the use of System properties defined when launching the server like
> "-Dapacheds.log.dir" and others.
yeah, a better option is to tell the user(or ask him to choose during
installation) to symlink
the directories present under the InstanceLayout, then it won't break
our program
ex. we want to find the pid of the server and getRunDir() will return
the linked /var/run
>> All these elements are well handled in the installers, we now have to
>> clarify the way they are used in the server.
yeap they are and personally am perfectly happy with them
> As I said, it will probably need to be double-checked in the installers.
>> One small last thing : currently, indexes files are named using the
>> Attribute OID. I find it not very friendly. Can't we use the Alias instead
>> ?
-1, there is a reason we changed back to OID, it is to avoid creating
duplicate indexes
on the same AT.

If we use alias then there is no way to check them,
e.x if user creates two indexes on "cn" and "commonName" then jdbm
creates "cn.db" and "commonName.db" which we cannot distinguish during

Another case is to find which indexes are no longer needed when user
removes them from config.

We store a OID.txt file with AT's definition alongside the index files
to let the user know what that indexed attribute is.

Though the above examples are applicable for JDBM based partition,
they all still hold good
for all types of partition implementations.

> +1, or the OID if the AT has no aliases.
this helps, but let us have a unique naming convention

Kiran Ayyagari

View raw message