directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [Shared] Thoughts on an M2 release?
Date Mon, 28 Feb 2011 19:53:20 GMT
On Mon, Feb 28, 2011 at 5:01 AM, Alex Karasulu <> wrote:
> Hi folks,
> The tasks for making controls, extended operations and the protocol
> codec factory totally pluggable are complete. I was just trying to add
> a couple archetypes for creating new control or extended operation
> projects. This might help us rapidly get setup to build new extended
> operations and controls while also helping our API users. This is low
> hanging fruit for now but the real work starts up again with making
> schema's pluggable as bundles.
> Before moving on to this which we can discuss in another thread, I
> wanted to check and see if y'all want to push out another milestone
> release? This way we get something into the hands of our users so we
> can get feedback.


> Also two other points.
> (1) We should probably build out an example web application using the
> LDAP API especially with all the Serializable removal work taking
> place. It might help validate what we should and should not make
> Serializable. Plus it might be a good application to show the API in
> action. Perhaps like a little simple LDAP administrative application.
> It can go into the manual or into the code examples. WDYT?

sounds good

> (2) Should we shoot for making the schema pluggable with schema
> bundles? Right now it's already dynamic. I don't know just how much
> value this adds but it would remove the need for schema dependency
> checking by our own system, this would be delegated to the OSGi
> container to determine what schemas a dependent schema depends on.
> There are some other benefits around classloaders and isolating the
> operation of loaded code. I could probably enumerate this better with
> some sleep :).

This is a very interesting question.

Currently when the server is started the first time all schemas are
imported into the schema partition (LDIF partition). Once this
initialization of the schema partition is done changes in the source
LDIF file is not promoted to the schema partition.

An idea is to switch the 'internal' schemas (system, core, apachemeta,
adsconfig) to bundles and not to import them into the schema
partition. This way we can update those schemas in a newer version.
Additional the user can't mess up those internal schemas.

I also think we should split up the adsconfig schema. Atm it contains
schema elements for configuring everything: interceptors,
authenticators, partitions, servers, etc. Whenever extending the
server the adsconfig schema needs to be updated. It would be nice if
each extension (interceptor, partition, server, etc.) would contain
everything to configure itself (schema elements, configuration beans,
builder to wire beans).

Kind Regards,

View raw message