directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [ApacheDS] Rename project 'server-config' to 'apacheds-server-config' + Move 'ConfigBuilder' class into a separate project
Date Tue, 16 Nov 2010 15:21:22 GMT
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 <pa@marcelot.net> 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


Mime
View raw message