BTW i forgot to mention about 3th party developers issue.

3th parties using OSGI can extend our schema elements with any way they want. IPojo,Blueprint, OSGI Services. IPojo is currently supported out of the box for Comparators(implementing for the other two is piece of cake from now on.) For the 3th parties not using OSGI, they can provide their classes with the Fragment bundles. Actually it is OSGI feature too. To be able get the class names of 3th parties that are not using Services we can introduce some extender bundle for watching bundles that are installed into framework those having some unique signature. Like <ApacheDS-Comparator>org.foo.BarComparator<ApacheDS-Comparator>. So when that extender sees that fragment being installed into framework, it can notify the shared to load that new class name to its internal list. 


Regards,
Gokturk

On Thu, Oct 20, 2011 at 4:48 AM, Göktürk Gezer <gokturk.gezer@gmail.com> wrote:
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