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.ge...@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
>
