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 <[email protected]> > 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 iPojo. > 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 nothing. > > 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: > org.apache.directory.server.config.ConfigurationException: Cannot initialize > the org.apache.directory.server.core.normalization.NormalizationInterceptor, > error : java.lang.ClassNotFoundException: > org.apache.directory.server.core.normalization.NormalizationInterceptor not > found by org.apache.directory.server.service.builder [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 > Regards, > Pierre-Arnaud > > [1] - http://cl.ly/C3eB > [2] - http://cl.ly/C3O s > > Regards, > Göktürk
