On Thu, Oct 6, 2011 at 8:10 PM, Emmanuel Lécharny <email@example.com>
On 10/6/11 12:29 PM, Göktürk Gezer wrote:
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 :
*Step1 (Implementing Modularity and Lifecycle)*
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.
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
Yes it seems fine. Having no conflict packages on APIs is a good news. I'll look into these packages.
We can first start by cleaning those conflicts.
Yeah. Modifying the poms is easy, adding 3rd parties poms is already done for Studio, we can probably inherit from what has been done
* 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.
+1. Not too complicated either.
* 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.
Can you tell us a bit more about Karaf ?
* Create a Karaf feature description xml file for deploying ApacheDS into
Karaf easilly with all of its dependencies.
Karaf is an OSGI container. It provides good management for OSGI framework of our choice. Easy deployment and configuration of bundles, remote management, and pretty good shell is some of karaf's cool features. Feature file i mentioned is used to deploy complete application with all of its bundles and dependencies into Karaf. This file simply lists the bundles required for ApacheDS to work. End-users can just download that xml file and then deploy ApacheDS into the Karaf using it.
IMO? this would be a one to two weeks work, max.
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.
Yeah, i think the same.
*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
* 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 :
- password policies
- schema elements (we have 7 different kind of them)
- each of the protocol we implemented (NTP, Kerberos, LDAP, etc)
- network layer (currently, we only use MINA)
- extended operations
(I may have missed some of them)
List is longer than i expected.
Now that all teh configuration is in DiT, this could be easier.
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.
Pretty much what I listed above, by I may have missed some aspects.
Actual substeps needed for implementing service layer will come out clearly
after we decided what aspects needs to be extendable.
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...).
Yes, there is no reason for us to wait on service decisions. The first part is mandatory anyway. But lets keep the service topic alive, because all it needs is more discussion before we can start implementing it.
Feel free to comment !
I guess we need a jira issue for me to attach patches. Are we going to create a branch, or work on the trunk?