On 10/19/11 9:08 AM, Pierre-Arnaud Marcelot wrote:
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).
To some extent, I feel a bit the same. It would be a real pain if we
require that our users include an OSGi container in order to use our API.
Now, is there a way to keep the schema elements class-loaded, without
having to make them bundles ?
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.
I think that it's not really a big issue, as we just need to modify the
test framework we use.
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).
True.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
