We could also introduce a mechanism to register and execute functors or callbacks.
To some degree Trustin tried to do this with primitive callback methods called by
the server startup. 
This is something to add to the list of things we definately need to refactor for an
elegant solution.  What we have now is unacceptable.  It was originally a workaround.
On 3/15/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
On 3/15/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> So far, may be the ReferralITest is close to what you want to do : it
> creates 3 sub contexts, and add entries into it, without using a LDIF file.
> This test case is in server-unit :
> http://svn.apache.org/viewvc/directory/apacheds/trunk/server-unit/src/test/java/org/apache/directory/server/ReferralITest.java?revision=499741&view=markup
> Hope it helps, and also that it's not OT.

Definitely not OT and I did use those ITests to get started.  As I
mentioned earlier, the issue is that the base DN for Kerberos searches
has to exist before the Kerberos PP starts.  Of course, this is
probably bad design and has to be fixed for multi-realm capability.
Today the problem is that the Kerberos PP starts on the first call to
ServerContextFactory.  As Alex noted, this leaves LDIF is the only way
to load prior to protocol startup.  So, without an LDIF those ITest
examples don't help because I'm doing somethings with Kerberos.  The
only other way around this is to rework ServerContextFactory; to
basically write a new one that allows configuration of the backend,
then backend startup, then makes a context available by
CoreContextFactory, then allows some control over the protocol startup

Anyway, my question was answered and we have more food for thought and
probably a JIRA issue.