directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [API][ApacheDS][Studio] Status on the OSGI branch
Date Tue, 29 Nov 2011 12:42:10 GMT
Hi Göktürk,

On 23 nov. 2011, at 17:36, Göktürk Gezer wrote:

> On Wed, Nov 23, 2011 at 5:31 PM, Pierre-Arnaud Marcelot <> wrote:
> Hi guys,
> I wanted to give you a little bit of feedback and ask for status from the other team
members (especially Göktük) working on the OSGI branch.
> On the API side, Göktük introduced extensibility for the comparators and syntax checkers
using Apache Felix iPojo.
> From what I've seen it works great both as OSGI bundles and plain old jars.
> That's cool. 
> On the Studio side, I'm still struggling with these modifications.
> Despite all my efforts and hacks (especially with the 'Bundle-ActivationPolicy' directive
of the MANIFEST.MF file), I'm still unable to load extensible elements of the API within Studio.
> Here's a quick recap of the problems I encountered.
> At first, I noticed that in Equinox (Eclipse's OSGI container), the iPojo bundle and
Shared's iPojo utilities bundle were not started and their activators not called when I was
using the API
> I rebranded the iPojo bundle in Studio's projects to include the 'Bundle-ActivationPolicy'
directive in its MANIFEST.MF file, and also included it in the 'ipojo-manager' of ApacheDS.
> This is already a bad hack, but it is still not enough…
> Now, both bundles are started at the first time one of their classes is accessed by another
bundle, and their activators are getting called correctly.
> However I'm still getting an exception, a NullPointerException.
> This NPE occurs when we ask the bundle context for the service references related to
> Here's a file containing the full stack trace of the exception: [1]
> At this point, there should be a service reference for iPojo ready to use, but we get
> This is how far I've managed to go… It is not enough, but I've tried every fix idea
I had and I empty now…
> If someone has a clever idea… ;)
> I just have ideas on why this is failing. The first thing to consider is, something in
eclipse equinox is preventing IPojo from actually initializing. I mean it seems started but,
actually it isn't.

On a standard configuration, iPojo isn't started at all. The activator is never called.
After a rebranding of the MANIFEST.MF file of the bundle (adding the 'Bundle-ActivationPolicy'
directive), the activator is called and the bundle is started. I could verify this via the
OSGI console in Eclipse and by setting a breakpoint in the bundle's activator.

> IPojo does not have custom equinox console command, so that makes finding out what happened
harder. If we assume IPojo is initialized correctly, then the problem is about the thread
model of the equinox which leads Ipojo annotated api elements(Comprators, etc...) to not registered
with IPojo before the code looks for them through IPojo. Starting them right after the IPojo
in equinox may solve the problem.

I also tried to manually schedule the start of the bundle using the OSGI console as well,
starting iPojo first and other Shared/ApacheDS bundles afterwards.
That didn't help much…
Still this NPE while getting access the iPojo services.

> Actually there is no nice-looking solution to this problem, because we're deploying osgi
partially into the code, so we must manage these problems somehow. I couldn't have a chance
to look at what is wrong with the studio. IPojo runs on equinox for sure. I'll try to set
my environment for debugging that problem.

I can help you with that if you like.

> On the ApacheDS side, I am able to run a small part of ApacheDS using the 'apache-felix'
module and its Eclipse launch configuration.
> At the end of the execution I hit this exception:
> Cannot initialize the,
error : java.lang.ClassNotFoundException:
not found by [44]
> Here's a file containing the full stack trace of the exception: [2]
> I think it is, at the moment, the intended behavior since a few things still remain to
be set in ApacheDS to allow it to run successfully within an OSGI container.
> Göktük, can you confirm this is the intended behavior please?
> Yeah, that's the same stacktrace with the one i get . Interceptors are not even visible
to service-osgi bundle, so NoClassDefFound is expected exception when we try to classload
them which is what we do right now. 

Cool, thanks for the confirmation.

> More importantly, can you share with us the status of the OSGI-fication of ApacheDS?
What is the purpose of the 'component-hub' you have been working on lately?
> component-hub is the main extendibility layer i'm working on. This will provide us as
developers a facility to provide extendibility to any aspect of the ApacheDS. It's almost
done with the implementation. It needs testing after that of course. It will be a standalone
engine in ApacheDS, means you won't have to use OSGI directly to provide extendibility. ComponentHub
provides facilities for, listening some type of components, creating instance of them, configuring
the instances through associated entries in DIT, saving and loading those created/configured
instances through java property files.
> So when we want to provide extendibility for interceptors lets say, we will write 3 class(schema
generator, instance generator and listener). Schema generator is for generating custom schema
elements to represent the component's instances on DIT. Instance generator in the other hand
must be compatible with its schema generator, and its purpose is generating instances with
the default configuration which we'll extract from the implementing class. When we register
schema generator and instance generator with the component-hub, our listener will start getting
information of all the interceptors in the system through callback methods with ADSComponent
argument. Through this ADSComponent reference we'll be able to create manage,create.configure
the component instances, easilly. Each created instance will also be represented by ADSComponentInstance
reference which will provide facilities for hooking its configuration with the some entry
on DIT and so..I already wrote general purpose schema-instance generators, but individual
component types may need some extra, hardcoded things in its schema and DIT entries, so that's
why i make generators extendible. I'll document the infrastructure after i finish and test
it completely. All i can say is after it finishes, making something in ApacheDS extendible
in all aspects will be really easy procedure.

OK, thanks for this overview. Sounds great for extensibility.

> I hope we can move forward and find fixes to all the remaining issues quickly on OSGI.
> Even if we merge back the modifications from trunk to the OSGI branch very often, it's
never a good idea for a branch to last too long… It usually make the last merge (when merging
back to trunk) a nightmare.
> With the component-hub working as standalone extendibility engine, there won't be major
changes in the code i guess.

That's good to know… :)

> But OSGI-fication of ApacheDS is some kind a incremental work, we'll face the problem
and solve it, so i can't accurately say when the ApacheDS will run on OSGI completely. I hope
the branch won't last longer than 2 month, but it's strongly needed right now even if ApacheDS
runs on OSGI tomorrow :)

Sure… Let's do it, step by step.


> Regards,
> Pierre-Arnaud
> [1] -
> [2] - s
> Regards,
> Göktürk

View raw message