implement the multi-source directory approach
#1 Updated by Greg Shah over 11 years ago
Change the current directory approach from the reading of a single database to having a runtime directory representation that is a combined "database" that is potentially created from multiple sources. There is a precedence order to the sources, such that conflicting nodes get resolved based on the higher priority sources.
Precedence (1 to 6 where 1 is highest priority and 6 is lowest):
1. command line (syntax for the server command line that specifies the node path, type and value)
2. bootstrap config (syntax for the config file that specifies the node path, type and value)
3. external directory (an application-specific directory that is explicitly specified for the server)
4. application jar directory (directory values in a directory XML file that is found in the application jar)
5. default jar directory (default directory values in a directory XML file that found in the P2J jar)
6. default directory values in the P2J code (put better defaults in and expand the amount of places with good defaults so that this minimizes what has to be put in the other places; this is a big effort on its own)
The result is a virtual directory used at runtime. The idea is that this is significantly easier to manage since it allows the maximum amount of standard stuff to be hidden away and only the stuff that is different must be specified. The various means of specification gives great flexibility to implementers.
#5 Updated by Greg Shah almost 8 years ago
It should really minimize per-site/per-system configuration and allow most things to be configured at the most appropriate level, including quite a bit that can come directly from the jar.
If you have any ideas to enhance this, we are certainly open to hearing them. Considering that you have done quite a bit of deployment work with P2J, you qualify as one of leading players in that exclusive community. :)
#6 Updated by Greg Shah over 7 years ago
An interesting question was posed by Igor:
-------- Forwarded Message -------- Subject: Command line arguments and DirectoryService Date: Wed, 21 Sep 2016 08:29:41 -0400 From: Igor To: ... Gentlemen, I have a question about the relation between command line arguments and Directory service. Imagine that I need to obtain a configuration value for the "net/xml/compress" configuration parameter at the server side. As far as I can see this can be done in two ways: 1. Specifynet:xml:compress argument in the command line and call a corresponding method of the BootstrapConfig. 2. Add <net> container under the <standard/runtime/default> in the directory.xml and use Utils.getDirectoryNodeBoolean call. Are these two ways "orthogonal"? More specifically: 1. Is it possible to override the directory.xml settings from the command line? 2. Is it possible to access settings specified in the command line with Utils.getDirectoryNodeXXX call? Thank you, Igor.
No the current design is not orthogonal.
The current implementation cannot override directory settings from the command line, but we want to provide this capability (see note 1 above).
The bootstrap configuration was originally designed to provide the minimum initial configuration to allow the server to start up. This means the values that are there are supposed to be ones that must be known before the directory has been read. Mostly it will include how to access the directory, passwords for keystores, truststores and some low level networking configuration. The client-side bootstrap config has the same idea except it is mostly about how to access the server, which client driver to use, some client-specific configuration values that must be known before the server can be contacted (in addition to the passwords for keystores, truststores).
#9 Updated by Greg Shah about 4 years ago
One customer mentioned to me that he would like to see the security sections of the directory as a separate XML file. The plan above may accommodate this idea though it is designed to be more general purpose (not just security portions).
He also really wanted a more condensed format for the contents of the directory, which we have planned as #2316.