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/protocol-ldap
/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
/org/apache/directory/shared/ldap/extras/controls/ppolicy
./shared/ldap/extras/codec
/org/apache/directory/shared/ldap/extras/controls/ppolicy
./shared/ldap/extras/codec-api
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,
etc...).
Feel free to comment !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
