directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <>
Subject Re: [ApacheDS 2.0] OSGI, Implementing Services
Date Wed, 19 Oct 2011 07:01:33 GMT
On Wed, Oct 19, 2011 at 9:05 AM, Emmanuel Lécharny <>wrote:

> On 10/19/11 6:35 AM, Göktürk Gezer wrote:
>> Hi Emmanuel,
>> I'm doing some experiments on DS. I saw some problems on our way. Before
>> diving deeper i must consult you about somethings.
>> I'm changing the way we deal with schema
>> elements(LdapComparator,**Normalizer,SyntaxChecker) so that they will be
>> pluggable. Schema manager tries to classload them that's where i'm going
>> to
>> change. I'll make SchemaManager get them through OSGI, but while i change
>> the core parts, there are lots of place on the code that use them as
>> tool(Tests espacially). And once the class is manipulated with IPojo, it
>> is
>> not so easy to instantiate it through normal ways. Before solving that
>> topic
>> i must know what do you think about below issues:
>> 1- Tests are using them heavily. So changing the way we load them will
>> broke
>> these unit tests. So we must change them to be OSGI compatible. I'm
>> talking
>> aside from OSGI integration tests. These changes will make these unit
>> tests
>> unable to run without OSGI.(Pax-Exam will be used most probably)
> I'm afraid this will be a necessary move...
>> 2- Because more than one instances of the ApacheDS may be launched inside
>> same JVM. We must either provide same copies of these schema elements to
>> all
>> instances or we must create separate ones for each one. They are separated
>> between instances at that moment because of the class load approach, but
>> as
>> far as i see no context information is kept in those elements. So we can
>> share them between ApacheDS instances. What do you think?
> Those 3 classes are totally context-free. We can share them safely.
>> 3- How Studio is interacting with that elements. This is the most
>> important
>> question actually. Because these elements are in shared, every main change
>> will affect Studio too. For what purposes these elements are being used by
>> Studio?
> Studio uses shared heavily. As the client API is schema aware, and as it's
> used by Studio, we are using those elements in many places in Studio.

Considering these classes are context free and being heavily used by Studio.
We must implement some hybrid model for them. Exposing them as plain OSGI
services using Activator won't break any other codes those using them,either
unit tests or Studio. We can collect them into some IPojo backed hub for
handling dynamism of OSGI. While the SchemaManager uses that hub to access
shared instances, the other parts can continue using them like the same

> I don't know how wide will be the changes, but as soon as we have a
> guideline to do them, we can apply it easily. It's just a matter of time !

It won't be that wide for that part as i described above. We can use that
approach for any other case which brings more problem that it solves like
this one.

> Thanks !
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

View raw message