directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject [ OSGI Branch ] status update
Date Sun, 13 May 2012 03:06:12 GMT
Hi Guys,

I'd like to give you an update on current status of the OSGI branch, and
ask your opinions on some topics...

First of all, now we have ApacheDS running in OSGI, capable of
reconfiguring itself on the fly (partially for now just for test, only
server itself along with interceptors and some other things.). And server
startup time is not bad, which i've always been suspicious about. Here are
the core features of component-hub.

*Developer features:*

* Hub is designed to work with any OSGI compliant Component Framework. Not
all frameworks can use all features of hub because of their own nature, but
now we have an aggregator layer which is able to work with every one of
them.
I used IPojo components while testing the integration, but also implemented
declerativeservices connector just as proof of concept, blueprint on the
way.

* Component Framework, Factories and Components are isolated from ApacheDS
code using abstractions, nothing OSGI specific goes into code.(of some
degree of course)

*Configuration Model:*

* Through hub, these configuration options can be described in LDAP and
passed to components, inside brackets are the compatible framework types.

      * Collections (List,Set,Array) (Only IPojo)
      * Any other component reference (Blueprint & IPojo)
      * Java Primitive types(all component framework)
      * Object injection,(This is any type like SchemaManager,
InstanceLayout, DirectoryService ext... can be injected into components)
(Blueprint & IPojo)

* Inside config-partition, no special hierarchy rule is necessary. We can
pick any placing as we see fit, and then change it, no worries.

* Configurations are updatable meaning if we update some component with new
version which has different configuration(additions/deletions) existing
configurations are updated to work with new component.( Some update types
are not possible, so we loose existing component descriptors, but works for
most of the scenarious.

*Runtime Model:*
*
*
* Through a special interceptor, ADD,DELETE,MODIFY operations on
config-partition are tracked and reflected to hub. Event listeners can be
attached to component-hub for getting component events, registrations are
class type based, so one piece of code can track what is going about
components implementing Interceptor.class in component-hub.

* For components having another components and collections as property, all
changes are propagated back to their parent. For IPojo only their setter
methods (if declared) are called too even if runtime Object reference is
not changed at all.

* Event trackers can take action in life-cycle events of components. This
feature is usefull for keeping ApacheDS away from dropping into
inconsistent configuration. For example, the test integration i implemented
mandates component-hub having at least one intreceptor for every
interception point in server.

*PROBLEMS:*
*
*
1- JDBM serialization uses plain ObjectInputReader for deserializing, which
is failing in an OSGI environment. We have find some nice way to handle
that, i handled it by adding required classes to boot delegation path of
OSGI, which is not viable for production. Our possible solutions are either
redeclaring these classes under JDBM and AVL (I don't know if possible) or
subclassing ObjectInputReader to delegate class loads to correct
class-loader in an OSGI environment.

2-  JDBM partition is so static. Any tiny reconfiguration after it's been
initialized throws an Exception out of nowhere. Under this runtime
characteristics i left out partitions in my initial integration tests. They
need some work to be done in order to be reconfigurable in
runtime.(Adding/removing user attribute index at runtime would be a good
start).

3 - I'm having nightmares with logging in eclipse-equinox. I just couldn't
find a way to adjust logging settings. Thanks to schema-loader's massive
DEBUG output, i'm left with System.out.println() here, having disabled
logging. Pierre i'd use a little help here :)

After these problems are solved, you'll be able to test and stretch the
system in your local copy. Until this time i'll improve it as much as i
can, and under your guidances i'll try to find some fit configuration model
for all server components.

Lets talk more !

Regards,
Gokturk

Mime
View raw message