[
https://issues.apache.org/jira/browse/DIRSERVER-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132712#comment-13132712
]
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 class.
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 appear.
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.
Solution:
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 ) != null;
}
What do you think about this solution?
Thanks,
Pierre-Arnaud
> Making Comparators extendable
> -----------------------------
>
> Key: DIRSERVER-1672
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1672
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
