directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [ADS 2.0] OSGi
Date Thu, 06 Oct 2011 17:10:14 GMT
On 10/6/11 12:29 PM, Göktürk Gezer wrote:
> Hi Emmanuel,
> I would like to elaborate the things about OSGI those we've talked with you
> and Alex here. So that we can have some road map.
> With respect to OSGI's 3 layer (modularity, lifecycle and services), we can
> divide our future efforts into 3 main step. Actually the first and second
> steps can be merged in one.
> *Step1 (Implementing Modularity and Lifecycle)*
> This step will contain mostly configuration changes on POM files.
> * As you've told, conflict packages problem must be solved or at least down
> to a minimum degree. For the situations those are impossible to completely
> solve that issue, we may look into the "fragments" feature that is designed
> for practically one bundle backing the other with extra content. However
> this is not an elegant solution. We must ensure the separation as much as we
> can.
I don't think we will have big issues removing the conflicting packages. 
Here is the list of packages present in more than one module :
/org/apache/directory/server ./apacheds/http-directory-bridge
/org/apache/directory/server ./apacheds/service
/org/apache/directory/server ./apacheds/wrapper
/org/apache/directory/server/config ./apacheds/server-config
/org/apache/directory/server/config ./apacheds/service-builder
/org/apache/directory/server/core ./apacheds/core
/org/apache/directory/server/core ./apacheds/core-api
/org/apache/directory/server/core/changelog ./apacheds/core
/org/apache/directory/server/core/changelog ./apacheds/core-api
/org/apache/directory/server/core/event ./apacheds/core
/org/apache/directory/server/core/event ./apacheds/core-api
/org/apache/directory/server/core/interceptor ./apacheds/core
/org/apache/directory/server/core/interceptor ./apacheds/core-api
/org/apache/directory/server/core/journal ./apacheds/core
/org/apache/directory/server/core/journal ./apacheds/core-api
/org/apache/directory/server/core/partition ./apacheds/core
/org/apache/directory/server/core/partition ./apacheds/core-api
/org/apache/directory/server/core/partition ./apacheds/ldif-partition
/org/apache/directory/server/core/replication ./apacheds/core
/org/apache/directory/server/core/replication ./apacheds/core-api
/org/apache/directory/server/core/schema ./apacheds/core
/org/apache/directory/server/core/schema ./apacheds/core-api
/org/apache/directory/server/core/schema ./apacheds/jdbm-partition
/org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
/org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
/org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
/org/apache/directory/server/kerberos/protocol ./apacheds/protocol-kerberos
/org/apache/directory/server/ldap/handlers/extended ./apacheds/server-tools
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/standalone
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec

We can first start by cleaning those conflicts.
> * After dividing the modules's packages properly, we're gonna introduce OSGI
> specific instructions into each modules POM, making them an OSGI bundle. And
> at that point we must introduce ApacheDS's 3th party dependencies as bundle
> imports into corresponding modules.
Yeah. Modifying the poms is easy, adding 3rd parties poms is already 
done for Studio, we can probably inherit from what has been done.

> * Modify the existing apacheds-service module (or add a new one) for
> embedding the felix, deploying the core and dependency bundles into it, and
> then starting the ApacheDS on top of Felix.
+1. Not too complicated either.

> * Create a Karaf feature description xml file for deploying ApacheDS into
> Karaf easilly with all of its dependencies.

Can you tell us a bit more about Karaf ?
> This first step is going to be mostly a configuration job. If we are lucky,
> there won't be much code changes at that step. Considering the fact that
> ApacheDS's code is designed to be embeddable, we are lucky. It already works
> as megabundle on all frameworks without modification.

IMO? this would be a one to two weeks work, max.
> *Step2 (Implementing Services)*
> *
> *
> Using services layer in ApacheDS will give you the runtime extendibility you
> want. But interacting with service layer may not be the wise choice. To deal
> with the wildly dynamic nature of the OSGI, we must use some component model
> on top of services. Considering two mainly used component frameworks,
> blueprint and IPojo, it seems IPojo is the correct choice. To list my
> reasons of this choice:
> * IPojo lets you describe the component model with annotations. It also
> accepts xml and also gives you the API to create your own way other than
> these two.
> * Its highly extendable, letting you implement your custom needs without
> need to change the core IPojo code.
> * Field injection feature of it is the perfect way for making existing code
> to use services with minimum modification.
> List goes long...
> Listing the things we must do for implementing service layer depends on what
> we want to do with it. For example we can provide partition implementations
> as services, so changing the code to see those arriving implementations in
> the form of implementing bundles and start to use them immediately.

We first have to list all the services we want. I assume we could have 
around 10 to 20 (max) services.

Some might be loaded only at startup, and never changed (or rarely), and 
others might be loaded at will, depending on what the user may do (for 
instance, I'm thinking about store procedures).

from the top of my head, here are some of the needed services :
- partitions
- authenticators
- password policies
- schema elements (we have 7 different kind of them)
- interceptors
- loggers
- each of the protocol we implemented (NTP, Kerberos, LDAP, etc)
- network layer (currently, we only use MINA)
- replication
- extended operations

(I may have missed some of them)
> The ability to configure the arriving component's(service's) configuration
> data inside ApacheDS DIT will be an ease for us, the 3th party component
> writers and the users. I implemented that feature as test research. It has
> some issues but not unsolvable, we just have to set the slider between speed
> and code clarity.
Now that all teh configuration is in DiT, this could be easier.
> Actual substeps needed for implementing service layer will come out clearly
> after we decided what aspects needs to be extendable.
Pretty much what I listed above, by I may have missed some aspects.

I suggest we start with the first step in any case, before thinking 
about implementing services, as we will face some serious questions when 
we will start with services (about service initialization, dependencies, 

Feel free to comment !

Emmanuel Lécharny

View raw message