directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giampaolo Tomassoni" <>
Subject Mitosis: what about a bit of meiosis?
Date Tue, 13 Sep 2005 08:47:09 GMT
I had a look at mitosis (

It is an interesting plug-in for apacheds, but I didn't yet managed to have it running and
I got a couple of design questions.

First, I see now it is limited to only one peer. Why? Is this due to some limit in the protocol?

It looks like mitosis is designed as an interceptor, so that updating requests from clients
are silently brought to the peer and there replicated. However, this means that:

1) even operations on my virtual BackingStore, i.e. the one which adds a virtual tree made
of aliases to real objects, would be replicated;

2) I don't see a way to have different sets of replicators for different BackingStore(s).

This is because Mitosis acts like an apacheds interceptor, so that client operations get replicated,
not BackingStore modifications.

The similarities between the apacheds' operation interceptors and the tomcat's ServletRequest
ones is shurely interesting and useful, but I would like to stress the fact that Tomcat lacks
any replication support: it borrows at most some load-balancing code, while relies on external
software to eventually replicate its datasources.

In this, the apacheds layout is different from tomcat one: the former supplies its own database
code (jdbm I guess), thereby users can't rely on external, replicated datasources. I believe
that the replication code, which seem a requirement to me for the goals of apacheds, would
be designed on top of the underlying jdbm.

I would like to stress also the fact that, yes, a Realm Controller may probably need only
a backing store, so that Mitosis could even work as an interceptor, but this way you're going
to clone even the limits of the MS Domain Controller: you will at most control only one domain
per machine. This is probably not a big issue, but in my professional experience I found often
that 4 computers (2 per domain) where really too much in a two-domain configuration...

Also, what about the Realm Controller equivalent of LOCAL_MACHINE objects? They are supposed
to be, well, local to one specific controller. They have not to be replicated. Think to stuff
like 'the eth0's ip address'. Better not to replicate that.

This can be accomplished by establishing replication in a per-BackingStore modality, thereby
having a couple of BackingStores: the local one (unreplicated, or better replicated to an
external, standby store), and the domain one (replicated, of course).

So, a bit of meiosis, in which the resulting cells "partially" share the same genetic code,
wouldn't be that bad. :)

Finally, I'm facing a problem with apacheds+mitosis.

I put a sample config in test.xml in the very same dir in which I have the apacheds jars +
the mitosis one.

If I do a:

	java -jar apacheds-main-0.9.2.jar test.xml

which was used to work with apacheds without mitosis, it complains this way:

SLF4J built for org.slf4j.impl.Log4jLoggerFA
log4j:WARN No appenders could be found for logger (org.apache.ldap.server.ServerMain).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" org.springframework.beans.factory.BeanDefinitionStoreException:
Error registering bean with name '' defined in file [/usr/src/apacheds-0.9.2/test.xml]: Bean
class [org.safehaus.mitosis.configuration.ReplicationConfiguration] not found; nested exception
is java.lang.ClassNotFoundException: org.safehaus.mitosis.configuration.ReplicationConfiguration
java.lang.ClassNotFoundException: org.safehaus.mitosis.configuration.ReplicationConfiguration
        at Method)
        at java.lang.ClassLoader.loadClass(
        at sun.misc.Launcher$AppClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
        at java.lang.ClassLoader.loadClassInternal(
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(
        at org.springframework.util.ClassUtils.forName(

If I'm so bad that do a:

	java -Xbootclasspath/a:apacheds-main-0.9.2.jar:safehaus-mitosis-0.1.jar -jar apacheds-main-0.9.2.jar

I get this:

SLF4J built for org.slf4j.impl.Log4jLoggerFA
0    [main] INFO  org.apache.ldap.server.ServerMain  - server: loading settings from test.xml
Exception in thread "main" org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerException))
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
        at org.apache.commons.logging.LogFactory.getLog(

The mitosis site doesn't explain where I am supposed to put the mitosis jar, but I guess that
putting it in the same directory of apacheds would suffice. Is apacheds looking for a jar
with a different name? The mitosis one I'm using is 'safehaus-mitosis-0.1.jar'.

Also, how I'm supposed to config the Log4j subsystem? I attempted creating a
file (which should be the default name) in the same dir where jars are, but not relief.

Everything under Linux, Java Blackdown-1.4.2-02, apacheds 0.9.2 and mitosis 0.1 (it is the
only one version available for download, but it seems there should be the 0.4 too).

I attach my test.xml as a reference.


Giampaolo Tomassoni - IT Consultant
Piazza VIII Aprile 1948, 4
I-53044 Chiusi (SI) - Italy
Ph: +39-0578-21100

View raw message