directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: [ApacheDS 2.0] OSGI, Implementing Services
Date Wed, 19 Oct 2011 07:40:09 GMT
On Wed, Oct 19, 2011 at 10:20 AM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> 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.
>
I i feel exactly the same too now.

>
> Now, is there a way to keep the schema elements class-loaded, without
> having to make them bundles ?

Yes, the hybrid way i described in previous mail can solve that.

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

If we go hybrid, we won't need to change them too. We will just provide
couple of OSGI integration tests.

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

I looked at the code a little bit. The only thing i saw in the relevant code
area that have enabled-disabled status, was schemas itself.the same schemas
can be enabled or disabled between instances, but once they're enabled they
all use the same Comparator,Normalizer and SyntaxCheckers as i see. I mean
as far as i see, this enabled-disabled context is kept in Schemas itself,
not in their attached (C)-(N)-(SC)s. Am I wrong?

By using IPojo we would have been describe our logic more elegantly, like
annotating our Comparator class with custom annotation like @Comparator and
that would be it. It would cost us more energy to implement but much more
ease to use. However this wouldn't save us from troubles we may fall into
with 3th parties and Studio. So, no worries, its not that much functionality
loss for that case.

>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>

Mime
View raw message