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. Alex On 3/15/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 3/15/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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 order. Anyway, my question was answered and we have more food for thought and probably a JIRA issue. Enrique
