directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: What should we do with apacheds-server-tools ?
Date Mon, 07 Jun 2010 08:30:00 GMT
+1.

I would add that with the removal of the server.xml file and the future changes in the InstallationLayout
of ApacheDS, the current implementation of the Server Tools will be completely irrelevant
and outdated.

What about starting a complete re-vamp of these tools for the 2.0 release (2.0.0 RC1 may been
ship without them but 2.0 final should be shipped with them) ?
I could work on that if you like as well as working on a newly installation layout since the
old one does not really makes sense now.

Regards,
Pierre-Arnaud

On 5 juin 2010, at 10:38, Stefan Seelmann wrote:

> Emmanuel Lecharny wrote:
>> Hi guys,
>> 
>> this module is broken since, pfeww, september 11 2008 (what a
>> coincidence ! Bad things always happen on 11/09...)
>> 
>> The question is : should we keep going and fix this module or should we
>> move it to the deceased projects ? A thrd option would be to make this
>> module a separate project we can release separately from ADS 2.0.
>> 
>> Wdyt is the best ?
> 
> I think we need to provide some CLI tools for administrating the server.
> At least we need a tool to re-build the index and to backup and restore
> the data in LDIF format including all operational attributes. Similar to
> OpenLDAP's slapindex, slapcat, and slapadd.
> 
> IMO the problem with the current tools is that they are dedicated to
> JDBM partitions and directly works on the *.db files.
> 
> Instead I think we should build those tools into the partition
> implementation. We could extend the Partition interface with some new
> methods:
>  void buildIndex();
>  void backup( File/URL toFile );
>  void restore( File/URL fromFile );
> and define extended operations to trigger those methods. The extended
> operations could be invoked from within Studio or from a new CLI tool.
> 
> Of course, the problem is (as always) time.
> 
> Kind Regards,
> Stefan
> 


Mime
View raw message