directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot (Commented) (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-1672) Making Comparators extendable
Date Fri, 21 Oct 2011 14:44:32 GMT


Pierre-Arnaud Marcelot commented on DIRSERVER-1672:

Hi Göktürk,

Good news, I was able to run the server this time. :)
I mean, until it crashes on the Syntax Checkers... But this is normal.

Congrats on the solution with iPojo. It seem to be fixing our classloading with OSGI issue
quite well.
I really like that it comes with only one new dependency (we try to keep them very low) and
that it only needs a few annotations here and there on the extensions (the comparators in
our particular example).

However, I noticed a few things that could be improved.

1/ Code duplication:
I've seen that, in order to be able to launch ApacheDS in both mode (JARs/OSGI), you had to
duplicate the DefaultSchemaManager class with an OSGISchemaManager class.
Same thing for the 'apacheds-service' project, which was duplicated with an 'apacheds-service-osgi'
project, and in which you explicitly use the OSGISchemaManager class instead of the DefaultSchemaManager

2/ Doesn't work as standard jars because of point 1:
This second thing is tightly linked to the other point.
Because the solution requires to explicitly use an OSGISchemaManager when in an OSGI container,
the LDAP API does not work when deployed in an OSGI environment.
The current code defaults to the original DefaultSchemaManager and then classloading issues
I tested this under Eclipse.
To verify this you need to remove the extra imported packages (which was a bloody hack for
our own use) in the pom.xml file of the 'shared-ldap-schema-data' project.

I think we can get rid of both points fairly easily (while keeping the iPojo solution, which
works really great).
My solution would be to let the schema manager detect in which kind of environment it is running
(deployed in an OSGI or not).
In that case, instead of duplicating the whole class, we would only have a method indicating
if we are running in an OSGI container. If we do, then we use your solution with iPojo for
loading the extensions and if we don't we simply use Class.forName(...).
In that case, there's no need to duplicate the 'apacheds-service' project anymore.
And, most importantly, the usage of the API does not differ from one mode to the other. The
code is exactly the same whether your using an OSGI container or not. I think this is a key
feature here.

Detecting if we are running in an OSGI container is very simple. Here's a method I've written:
    public static boolean isRunningInOsgiContainer()
        return org.osgi.framework.FrameworkUtil.getBundle( DefaultSchemaManager.class ) !=

What do you think about this solution?

> Making Comparators extendable
> -----------------------------
>                 Key: DIRSERVER-1672
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>    Affects Versions: 2.0.0-M4
>            Reporter: Göktürk Gezer
>              Labels: apacheds, osgi, shared
>             Fix For: 2.0.0-M4
>         Attachments: comparator_extension.diff
> To provide 3th parties an ability to write their own schema elements, the first part
is making LdapComparators pluggable to shared-ldap-model. And existing clients must be preserved
as well.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message