directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [ApacheDS 2.0] OSGI, Implementing Services
Date Wed, 19 Oct 2011 07:08:30 GMT
Hi Göktürk,

On 19 oct. 2011, at 06:35, 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).

Although I'm 100% positive to move ApacheDS as a whole into OSGI, I'm *really* not sure the
LDAP API should rely on OSGI features for it's extensibility.

As an API, it's meant to be used by many third party developers and I personally think we
can't afford to be only compatible with OSGI. I'm afraid we still need to support the API
as a set of simple jars (that's why we added the 'standalone' project at the time with Alex,
supporting both OSGI and non-OSGI environments).

> 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)

Indeed, the framework will need, just like the ApacheDS service project, to start it's own
embedded OSGI container (Felix or Karaf) and launch the server through it.

> 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?

I not sure these can be shared between ApacheDS instances. Two instances can have very different
schemas (with schema elements having different 'enabled' states from one instance to the other
for example). 

> 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?

There are many places where Studio uses the LDAP API (Shared) classes. If we're talking only
about schema elements, they are heavily uses in the LDAP Browser (when loading the schema
from the remote connection) and in the SchemaEditor.
We're also using some ApacheDS classes (which work fine via OSGI, before when I rebranded
ApacheDS jars as bundled, and also now that they are real bundles), especially the configuration
classes for ApacheDS and the core partition classes. ApacheDS dependencies are only used in
the ApacheDS *2.0* Configuration Editor.

Regards,
Pierre-Arnaud

> Regards,
> Gokturk


Mime
View raw message