You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Göktürk Gezer <go...@gmail.com> on 2011/10/18 16:03:50 UTC
[ApacheDS 2.0] OSGI, Implementing Services
Hi Emmanuel,
Services can be implement into ApacheDS . Good mix of OSGI itself and IPojo
will let us do everything we wanted to make ApacheDS an OSGI application.
Later changes to the code will make it dependent on OSGI Framework. So i'm
waiting for a branch as we talked. I think, if we apply minor changes to the
branch also, we can avoid merging pain to some degree.
Regards,
Gokturk
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Oct 19, 2011 at 10:08 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>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.
>
>
Right I think we all agree that we need to be modal. The LDAP API is POJ
where in ApacheDS and Studio it will adapt to participate in the OSGi
environments accordingly with OSGi mechanisms.
> 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).
>
>
Yes I fully agree.
> > 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.
>
>
+1
> > 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).
>
>
Let's not share these classes across multiple instances because schema state
management although not represented directly on these class instances might
later introduce state into the picture. Sharing does not gain enough for us
to warrant the overhead in less flexibility and accessing shared schema
class instances.
Plus later on one instance might want to unload and reload the same
comparator but change it's implementation on reload. Shared instances will
not allow for this scenario.
--
Best Regards,
-- Alex
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Awesome!
I'm going to switch workspaces and see how well it works in both environments.
Regards,
Pierre-Arnaud
On 25 oct. 2011, at 17:30, Göktürk Gezer wrote:
> Hi Guys,
>
> Comparators, Normalizers and SyntaxCheckers are modified to be extendible in OSGI and left the same in non OSGI environments.
>
> I removed the "String compType" property that i wrote in every Comparator, and didn't use it on Normalizers and SyntaxCheckers. Because it was a piece of some advanced extendibility layer that we can't apply to a shared api.(Due to reasons we discussed for days).
>
> I guess we're almost done with the api, so we can start implementing some real extendibility layer for Interceptors.
>
>
> Regards,
> Göktürk
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Göktürk Gezer <go...@gmail.com>.
Hi Guys,
Comparators, Normalizers and SyntaxCheckers are modified to be extendible in
OSGI and left the same in non OSGI environments.
I removed the "String compType" property that i wrote in every Comparator,
and didn't use it on Normalizers and SyntaxCheckers. Because it was a piece
of some advanced extendibility layer that we can't apply to a shared
api.(Due to reasons we discussed for days).
I guess we're almost done with the api, so we can start implementing some
real extendibility layer for Interceptors.
Regards,
Göktürk
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Alex Karasulu <ak...@apache.org>.
On Wed, Oct 19, 2011 at 10:20 AM, Emmanuel Lecharny <el...@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.
>
> Now, is there a way to keep the schema elements class-loaded, without
> having to make them bundles ?
>
>
And this probably is the thought that triggered inquiries into using
fragments here.
--
Best Regards,
-- Alex
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Göktürk Gezer <go...@gmail.com>.
On Wed, Oct 19, 2011 at 10:20 AM, Emmanuel Lecharny <el...@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
>
>
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Göktürk Gezer <go...@gmail.com>.
On Wed, Oct 19, 2011 at 9:05 AM, Emmanuel Lécharny <el...@apache.org>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
before.
>
> 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
> www.iktek.com
>
>
Regards,
Gokturk
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Emmanuel Lécharny <el...@apache.org>.
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.
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 !
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Göktürk Gezer <go...@gmail.com>.
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)
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?
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?
Regards,
Gokturk
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Göktürk Gezer <go...@gmail.com>.
On Tue, Oct 18, 2011 at 5:10 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 10/18/11 4:03 PM, Göktürk Gezer wrote:
>
>> Hi Emmanuel,
>>
>> Services can be implement into ApacheDS . Good mix of OSGI itself and
>> IPojo
>> will let us do everything we wanted to make ApacheDS an OSGI application.
>>
>
> I'll create a apacheds-osgi branch asap. Do we need a shared-osgi branch
> too ? Or should I create a trunks-osgi branch mapping to the two other
> branches ?
shared-ldap-extras may be a problem. So lets branch them all.
>
>
>> Later changes to the code will make it dependent on OSGI Framework. So i'm
>> waiting for a branch as we talked. I think, if we apply minor changes to
>> the
>> branch also, we can avoid merging pain to some degree.
>>
> Hope so !
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: [ApacheDS 2.0] OSGI, Implementing Services
Posted by Emmanuel Lécharny <el...@apache.org>.
On 10/18/11 4:03 PM, Göktürk Gezer wrote:
> Hi Emmanuel,
>
> Services can be implement into ApacheDS . Good mix of OSGI itself and IPojo
> will let us do everything we wanted to make ApacheDS an OSGI application.
I'll create a apacheds-osgi branch asap. Do we need a shared-osgi branch
too ? Or should I create a trunks-osgi branch mapping to the two other
branches ?
>
> Later changes to the code will make it dependent on OSGI Framework. So i'm
> waiting for a branch as we talked. I think, if we apply minor changes to the
> branch also, we can avoid merging pain to some degree.
Hope so !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com