Thanks very much for taking the time to address my query! Some comments inline...

On 9/7/05, Alex Karasulu < > wrote:
Norbet Reilly wrote:

> Hi DS-ers,


> My immediate concern is supporting a custom back-end LDAP partition
> which has its own schema, prior to the availability of RFC 3672
> support (which sounds like it will smooth the way in the future).

It sure will.  You'll be able to define an autonomous administrative
point for the context of your partition to manage all the aspects of the
DIT therein.

I'm going to do a bit more reading so I understand this RFC fully.

> I have plugged in my custom LDAP AbstractContextPartition successfully
> (using the IETF LDAP classes to convert JNDI back to LDAP) and have
> written some support classes which fetch the remote
> org.ietf.ldap.LDAPSchema (during doInit() using some credentials known
> from the partition's configuration properties) and internalise it into
> the org.apache.ldap.server.schema.GlobalRegistries instance (noting in
> the future AbstractBootstrapProducer should ideally inherit from an
> abstract intermediate class to ease writing of classes like mine which
> create non-bootstrap instances of classes extending
> AbstractAttributeType/AbstractSchemaObject etc) .   ...what a sentence...

Made sense to me.

> My question is: what is the best way to get the ApacheDS server's
> org.apache.ldap.server.schema.SchemaService to notice that additions
> have been made to the GlobalRegistries.

Nothing like this so far.  Really the schema subsystem is extremely
primitive.  In fact we never intended to use the boostrap mechanism for
anything other than supporting some critical schema elements for the
system partition.  Now we're using the bootstrap mechanism for the whole

Part of this is my fault.  I waited until 3672 came since this would
give me the opportunity to really think about doing schema the right way.

Cool, I was just wanting to check that I hadn't missed something in the existing codebase.

> I notice the addition of AddContextPartitionConfiguration in ApacheDS
> 0.9.2, but I'm not sure hwo to configure its use via an ApacheDS
> configuration file (or even if it is indeed the answer to my problems).

Nah this is something else totally.  It's for dynamically adding and
removing partitions after system startup.

Ultimately there will be some linkage as the dynamically added partition will need to inform the DS core of some of its features, but of course that isn't relevant until the pathway for this information is known ;-)

> Failing that the only other approach I can think of is to get the
> startup infrastructure to create a back-end InitialContext very early
> so that my custom partition is queried for its schema just after the
> bootstrap schemas are processed, which sounds a very experimental path
> to follow.

Yeah you're not in a very good situation actually.  There really is no
clean way to solve your problem.  We just need to implement the Schema
subsystem properly.  You interested in giving that a try?

I'm working as a permanent employee currently, so I might need to come up with a short term solution initially (assuming that is possible). Once I've read the RFC more thoroughly and formed of picture in my mind of the work required, then I may consider asking my employer for permission to work on the schema subsystem. While there is mutual benefit, and assuming the amount of work required is not enormous, I've got a fairly good chance of a favourable response.

I should also mention that my interested in DS is to act as an intermediate proxy between an existing C++ client and a directory, where there is a strong focus on avoiding (or at least minimising) changes to client. Thinking about it, supporting the RFC 3672 stuff would most probably mean zero change to the client.

Do you have any rough idea of a) the design and b) the amount of time you guess it would take you to come up with a solution (I'd double it at least, given my very limited exposure to the DS codebase/architecture).

> Note that attempting to refresh the schema via JXplorer never seems to
> have any effect (I imagine that somewhere in the server it is assumed
> that there are only bootstrap schemas).

You guessed right ... schema is static on startup.

> Any guidance would be very much appreciated!

Sorry can't really give you a better way here other than to build out
the schema subsystem so it can support your needs.  This means just
implementing it properly.  There is no other trick we can use at the moment.


Thanks again for taking time to answer my query.

I'm off to read the RFC and scout the DS codebase and see if I can come up with a guesstimate for the schema subsystem support!