Hi Stefan, On 16 nov. 2010, at 16:12, Stefan Seelmann wrote:
> Hi Pierre-Arnaud, > > On Tue, Nov 16, 2010 at 3:48 PM, Pierre-Arnaud Marcelot <[email protected]> > wrote: >> Hi Dev, >> >> I'd like to propose two modifications for ApacheDS projects. >> >> I think the project 'server-config' should be renamed as >> 'apacheds-server-config' (to be consistent with others projects). It's the >> only project starting with a 'server' string and all other projects have a >> name starting with 'apacheds-something'. > > +1 > >> I'd also like to split the 'server-config' project in two parts. >> The first part, which would contain most of the classes and resources, will >> be responsible for reading the server config and generating config beans out >> of it. >> The second part would only contain the ConfigBuilder class which instantiate >> 'real' server objects out of the config beans (this part would depend on the >> first part of course). >> >> This is particularly important for Studio. >> With this separation the first part has very few dependencies (which is >> great and easy to use in Studio): >> - apacheds-core-api >> - apacheds-i18n >> - apacheds-ldif-partition ('test' scope) >> - apacheds-xdbm-partition >> - shared-ldap >> - junit-addons ('test' scope) > > I guess the remaining dependencies are required to be able to read and > write the config partition directlly from the local file system? Indeed. Emmanuel will need to confirm this but I think we're only able to read the config at the moment. I don't think a writer has been created yet. The LDIF writer should be pretty easy to write with what we already have. > What is the plan to read the config partiton over the wire? Maybe we could use the LDAP API to load the whole subtree under 'ou=config' and create an in-memory partition that we could pass to the existing configuration reader. The 'over the wire' writer will be much more complicated than the LDIF one, as it will have to deal with an existing set of entry. As I already explained to Emmanuel (on face-to-face conversations), we will probably need a structure to compare LDAP Trees, the original one and the new one. From these two trees we can then compute the needed modifications, which can be applied via the LDAP API. > Kind Regards, > Stefan
