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 Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 01:48:22 GMT
Hi Emmanuel,Pierre

I just attached my current work on Comparators to #DIRSERVER-1672. So here
is the explanation of how it works and how we can improve.

Because both issues i asked are ambigious. I decided to keep them both. I
mean Comparators are not shared and their OID is also assignable. First of
all, existing clients are ok with these changes. Object code manipulation
did not brake the nonOSGI clients now, and i keep the old semantic of
monolithic code exactly the same. Clients can continue using and
instantiating Comparator classes without OSGI. IPojo related problems on
that are resolved. keeping OID assignments in OSGI was so hard because
constructor(String)s of Comparators was preventing default parameterless
constructors to be created, which is IPojo's default way of creating
components. After struggling with IPojo's source code a little, i found a
solution to that too, which is constructor argument injection feature.

Comparator class definitions are changed like the example below:

@Component
@Provides
class BooleanComparator implements LdapComparator<String>
{
    @Property(name="ads.comp.type",value="comparator")
    public String compType;

    ...................
    ..............
    public BooleanComparator( @Property(name="ads.comp.comparator.oid")
String oid )
    {
     ......................
    }
}

The first two annotations are for making IPojo publishing a factory for
BooleanComparator class. It's not an instance, the first thing that
published is a factory which can be used to create instances of it, and i'm
using  it later to create an instances of that type. It is normally as easy
as putting @Instantiate annotation additionaly, but it does not fit in our
case, so i had to access factories manually.

The first @Property annotation is for publishing component type of a
component. This property is not being used right now, and if we decide to go
on with that, i will replace it with custom annotation on top of class like
@AdsComparator. The second @Property is for constructor parameter. While
creating instance using factory we 'll provide a configuration propery by
name "asd.comp.comparator.oid" which will be injected to constructor as
parameter and the component's underlying object will be created with that
constructor. So the either way (OSGI and normal) creating the component will
go through the same constructor.

In order to be able create these IPojo instances i created,
shared-ipojo-manager project with some helpers and main SchemaElementManager
class which is for loading intended schema element (only Comparator is
implemented by now, but the other two are just copy and modify job). 2 new
versions of SchemaElementFactory class' two method, getLdapComparator() and
classLoadComparator(), is created to allow using
ipojo-manager.SchemaElementsManager in order to get class references through
OSGI. Just additions at that level, no deletions. Only thing i changed that
brokes the standalone ApacheDS is in DefaultSchemaManager.addComparators()
method. I changed it to use SchemaElementFactory's OSGI versioned methods
instead of the old ones. Actually if i move those changes above from
DefaultSchemaManager the ApacheDS can still run as standalone application(if
it makes any sense)

I did it as demonstration, so sorry about not putting so much comments at
the code, But the information i provided here will help you review the code
mostly.

BTW, FYI i will be mostly MIA for next 5 days. Have very heavy exam
schedule. But i'll keep up with the mails for further discussions.


Regards,
Göktürk

Mime
View raw message