[ADS 2.0] OSGi

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

we have had some plan to make ADS OSGi compliant for 2.0. I think it's 
time to move forward.

Right now, we have reorganized shared in order to make it somehow OSGi 
compliant (well, at least the bare minimum has been done), but it's not 
enough. And on the server side, we have almost everything to do.

We have three aspects to consider :
- modularization
- lifecycle
- services

The very first step is to create modules. That means we must be sure we 
don't have conflicting packages (we have a few in the server). In order 
to do that, we must identify the different modules.
I suggest we first focus on this aspect atm, because it will shake the 
code a lot.

As I'm not (yet :) and OSGi expert, please feel free to push any ideas 
you have about a decent roadmap to get this done.

Thanks !

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

Re: [ADS 2.0] OSGi, interceptors : status

[Göktürk Gezer <go...@gmail.com>]

Hi Emmanuel,

On Fri, Oct 14, 2011 at 7:36 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> Ok, as of today, I have a working trunk (all tests passing).
>
> The main modifications are :
> - we have one sub-project under apacheds, 'interceptors', which is the root
> for all the interceptors. It's a pom
> - each interceptor is under this sub-project, and currently produce a jar
> - I had to create a core-shared project in order to avoid cyclic
> dependencies between interceptors and core. Currently, interceptors depend
> on core-shared, and core depends on all the interceptors plus core-shared.
>
We're going to change that behavior so that core will not be dependent on
any interceptor as class reference.

> - I had to replace the XXX.class.getName() (where XXX is an interceptor
> name) by the direct interceptor name in the ByPass collections. This has a
> direct impact : we now name interceptors using their simple name (ie,
> without the package). This is not good, but this is just temporary
>
Yes, maybe i must implement some helper for you to get class reference of
intended interceptor using its name.

> - I also had to register the SimpleName for interceptors all over the code
> (not that many refs, though)
>
> The things we should do :
> - we still have interceptors depending on other interceptors. This is not
> good, and I will try to get rid of those dependencies
> - we must find a way to manage the chain by using an abstract name, not the
> Interceptor class name. Same for byPasses.
>
I'm on it. Basically we can handle this by using filtering while getting
interceptor references through OSGI. And this basic thing will help us to
get rid of all inter and intra interceptor dependencies.

>
> The worst part of the work was surprisingly not the decoupling, but the
> pom.xml modifications...
>
> I will commit my current changes, be ready for many modifications.
>

So we must provide custom OSGI build of ApacheDS as first step ASAP. That
will help us identifying problems of bundleizing current code. I'm on it
primarily.

>

Thanks !


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

Re: [ADS 2.0] OSGi, interceptors : status

[Alex Karasulu <ak...@apache.org>]

First off a great effort ... thanks Emmanuel.  More inline ...

On Fri, Oct 14, 2011 at 7:36 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> Ok, as of today, I have a working trunk (all tests passing).
>
> The main modifications are :
> - I had to create a core-shared project in order to avoid cyclic
> dependencies between interceptors and core. Currently, interceptors depend
> on core-shared, and core depends on all the interceptors plus core-shared.
>

This might eventually go away with further refactoring which removes
interceptor coupling.


> The things we should do :
> - we still have interceptors depending on other interceptors. This is not
> good, and I will try to get rid of those dependencies
>

There are some cases where we have data structures that are members of
Interceptors where they should really be first class data structures that
are members of the DirectoryService. For example in the SubentryInterceptor
there are data structures that should be part of the directory service but
are embedded inside the interceptor making other interceptors have to depend
on the SubentryInterceptor.

To fix these kinds of problems a new first class service (i.e.
SubtreeService) can be introduced under the DirectoryService which also
happens to have a SubentryInterceptor that acts as an interception helper.
However other Interceptors ask this service for information to perform their
tasks instead of having a direct handle on the SubentryInterceptor itself.

-- 
Best Regards,
-- Alex

Re: [ADS 2.0] OSGi, interceptors : status

[Emmanuel Lécharny <el...@apache.org>]

Ok, as of today, I have a working trunk (all tests passing).

The main modifications are :
- we have one sub-project under apacheds, 'interceptors', which is the 
root for all the interceptors. It's a pom
- each interceptor is under this sub-project, and currently produce a jar
- I had to create a core-shared project in order to avoid cyclic 
dependencies between interceptors and core. Currently, interceptors 
depend on core-shared, and core depends on all the interceptors plus 
core-shared.
- I had to replace the XXX.class.getName() (where XXX is an interceptor 
name) by the direct interceptor name in the ByPass collections. This has 
a direct impact : we now name interceptors using their simple name (ie, 
without the package). This is not good, but this is just temporary
- I also had to register the SimpleName for interceptors all over the 
code (not that many refs, though)

The things we should do :
- we still have interceptors depending on other interceptors. This is 
not good, and I will try to get rid of those dependencies
- we must find a way to manage the chain by using an abstract name, not 
the Interceptor class name. Same for byPasses.

The worst part of the work was surprisingly not the decoupling, but the 
pom.xml modifications...

I will commit my current changes, be ready for many modifications.

Thanks !


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

Re: [ADS 2.0] OSGi, interceptors : status

[Alex Karasulu <ak...@apache.org>]

Nicely done and not an easy feat.

Thanks,
Alex

On Fri, Oct 14, 2011 at 1:46 AM, Emmanuel Lecharny <el...@gmail.com>wrote:

> Hi,
>
> as of tonite, I have almost all the interceptors correctly decoupled. I
> have created another extra project, core-shared, containing the elements
> used by the various interceptors. Now, the core project can reference the
> interceptors and core-shared.
>
> I still have to cleanup the poms, but I'm a bit tired to do it tonite (it's
> 1 am), I'll do t tomorrow.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Best Regards,
-- Alex

Re: [ADS 2.0] OSGi, interceptors : status

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

as of tonite, I have almost all the interceptors correctly decoupled. I 
have created another extra project, core-shared, containing the elements 
used by the various interceptors. Now, the core project can reference 
the interceptors and core-shared.

I still have to cleanup the poms, but I'm a bit tired to do it tonite 
(it's 1 am), I'll do t tomorrow.

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

Re: [ADS 2.0] OSGi, interceptors

[Emmanuel Lécharny <el...@apache.org>]

On 10/13/11 4:30 PM, Alex Karasulu wrote:
>
>>
>>>   I tried to play around the idea yesterday in the train, and I faced some
>>>>>>> interesting challenges.
>>>>>>>
>>>>>>> o First, many interecptors are doing calls to the chain again, but
>>>>>>> with
>>>>>>> a
>>>>>>> restricted set of interceptors. For instance, in the
>>>>>>> SchemaInterceptor,
>>>>>>> we
>>>>>>> go through the chain again when modifying the schema itself. In order
>>>>>>> to
>>>>>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm
>>>>>>> not
>>>>>>> sure it's a good idea, but right now, this is how we proceed). At the
>>>>>>> end,
>>>>>>> this BYPASS set is declared this way :
>>>>>>>
>>>>>>>     private static final Collection<String>    BYPASS;
>>>>>>>
>>>>>>>     static
>>>>>>>     {
>>>>>>>         Set<String>    c = new HashSet<String>();
>>>>>>>         c.add( AuthenticationInterceptor.******class.getName() );
>>>>>>>         c.add( AciAuthorizationInterceptor.******class.getName() );
>>>>>>>         c.add( DefaultAuthorizationIntercepto******r.class.getName()
>>>>>>> );
>>>>>>>         c.add( ExceptionInterceptor.class.******getName() );
>>>>>>>         c.add( SchemaInterceptor.class.******getName() );
>>>>>>>         BYPASS = Collections.******unmodifiableCollection( c );
>>>>>>>
>>>>>>>
>>>>>>>     }
>>>>>>>
>>>>>>> As we can see, it creates a static dependency on interceptors. It
>>>>>>> might
>>>>>>> be
>>>>>>> a better idea to use logical names instead of class names, and let the
>>>>>>> OSGi
>>>>>>> container retrieve the classes itself.
>>>>>>>
>>>>>>>
>>>>>>>   This is a good idea. How about going a little further and having a
>>>>>>> set
>>>>>>>
>>>>>> of
>>>>>> interceptor chain re-entry constants or set of enum values like:
>>>>>>
>>>>>> ReEntry.NO_AUTHENTICATION
>>>>>> ReEntry.NO_AUTHORIZATION
>>>>>> ReEntry.NO_ERROR_CHECKING
>>>>>> ReEntry.NO_SCHEMA_CHECKING
>>>>>>
>>>>>> etc ...
>>>>>>
>>>>>> This is like saying we do not need authentication, authorization,
>>>>>> additional
>>>>>> exception handling and checks or schema checking on re-entry instead of
>>>>>> having a direct list of interceptors to avoid.
>>>>>>
>>>>>>   That's a good idea.
>>>>> One thing that might be problematic though is that we have no idea which
>>>>> interceptors are going to be present in the chain, so we may be unable
>>>>> to
>>>>> tell the chain not to use the interceptors added on the fly (for
>>>>> instance,
>>>>> the logger interceptor).
>>>>>
>>>>>
>>>>>   Good point. Perhaps this is where we can have some kind of generic
>>>> property
>>>> that states whether or not by default on re-entry the interceptor should
>>>> be
>>>> included or excluded. There's a system default, say exclude by default
>>>> always. Then the interceptor might override this with some class property
>>>> like excludeOnReentry?
>>>>
>>>> This way even though the IC does not know which interceptors are present
>>>> it
>>>> can react accordingly on reentry. So for this logger interceptor example
>>>> it
>>>> might have excludeOnReentry set to false in which case it will always be
>>>> included when present which makes send. We would not add the interceptor
>>>> if
>>>> we did not want to log reentrant invocations.
>>>>
>> IMO, the best would be to declare sets of (I) we should go through, instead
>> of sets of (I) we should bypass. This way, we will be able to know what is
>> being executed, and we won't provide a way for users to pollute the internal
>> executions of operations (keep in mind that those internal operation are
>> themselves called by other operations).
>>
>> We can also declare those sets in the configuration, for each operation, so
>> if we want to allow someone to modify the execution order, it's still
>> possible to do so. (it can be done later though).
>>
> Perhaps we should break this out and discuss this in a separate thread. The
> reason historically for listing what you should not execute was a poor
> attempt to decouple and well you just don't know what extra interceptors you
> have.
>
> I have some ideas here that I also want to think through as well then post.

Sure, create another thread.



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

Re: [ADS 2.0] OSGi, interceptors

[Alex Karasulu <ak...@apache.org>]

On Thu, Oct 13, 2011 at 5:01 PM, Emmanuel Lecharny <el...@gmail.com>wrote:

> On 10/13/11 3:16 PM, Göktürk Gezer wrote:
>
>> Hi Emmanuel,Alex
>>
>> I would like to add something to discussion.
>> More inline...
>>
>> On Thu, Oct 13, 2011 at 3:23 PM, Alex Karasulu<ak...@apache.org>
>>  wrote:
>>
>>
>>> On Thu, Oct 13, 2011 at 3:05 PM, Emmanuel Lécharny<el...@apache.org>
>>> **wrote:
>>>
>>>  On 10/13/11 1:44 PM, Alex Karasulu wrote:
>>>>
>>>>  On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<
>>>>> elecharny@apache.org>
>>>>> **wrote:
>>>>>
>>>>>
>>>>>  Hi,
>>>>>
>>>>>> Göktük asked if there is a way to transform Interceptors to be bundles
>>>>>> instead of being statically loaded in core.
>>>>>>
>>>>>>  This can be case yes, but i actually wanted them for further
>>>>>
>>>> interceptors. We can keep core interceptors in place. Don't need to
>> separate
>> them all. Lets keep core interceptors in apacheds-core, and protocol
>> specific interceptors in their protocol implementation. And then any other
>> interceptor that comes and registers itself through OSGI can be attached
>> to
>> DirectoryService's interceptor list.
>>
>
> I'd rather decouple the whole thing. There is no reason for core to depend
> on Interceptors.
>

I'm in agreement here as well. Even if this is done as an exercise it will
clean up a lot of ugly coupling crust resident in the code. It's a bit
extreme but it has value and maybe will allow replacement of core
functionality easily down the line. It gives us more options in the end.


>
>
>>  I tried to play around the idea yesterday in the train, and I faced some
>>>>>> interesting challenges.
>>>>>>
>>>>>> o First, many interecptors are doing calls to the chain again, but
>>>>>> with
>>>>>> a
>>>>>> restricted set of interceptors. For instance, in the
>>>>>> SchemaInterceptor,
>>>>>> we
>>>>>> go through the chain again when modifying the schema itself. In order
>>>>>> to
>>>>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm
>>>>>> not
>>>>>> sure it's a good idea, but right now, this is how we proceed). At the
>>>>>> end,
>>>>>> this BYPASS set is declared this way :
>>>>>>
>>>>>>    private static final Collection<String>   BYPASS;
>>>>>>
>>>>>>    static
>>>>>>    {
>>>>>>        Set<String>   c = new HashSet<String>();
>>>>>>        c.add( AuthenticationInterceptor.******class.getName() );
>>>>>>        c.add( AciAuthorizationInterceptor.******class.getName() );
>>>>>>        c.add( DefaultAuthorizationIntercepto******r.class.getName()
>>>>>> );
>>>>>>        c.add( ExceptionInterceptor.class.******getName() );
>>>>>>        c.add( SchemaInterceptor.class.******getName() );
>>>>>>        BYPASS = Collections.******unmodifiableCollection( c );
>>>>>>
>>>>>>
>>>>>>    }
>>>>>>
>>>>>> As we can see, it creates a static dependency on interceptors. It
>>>>>> might
>>>>>> be
>>>>>> a better idea to use logical names instead of class names, and let the
>>>>>> OSGi
>>>>>> container retrieve the classes itself.
>>>>>>
>>>>>>
>>>>>>  This is a good idea. How about going a little further and having a
>>>>>> set
>>>>>>
>>>>> of
>>>>> interceptor chain re-entry constants or set of enum values like:
>>>>>
>>>>> ReEntry.NO_AUTHENTICATION
>>>>> ReEntry.NO_AUTHORIZATION
>>>>> ReEntry.NO_ERROR_CHECKING
>>>>> ReEntry.NO_SCHEMA_CHECKING
>>>>>
>>>>> etc ...
>>>>>
>>>>> This is like saying we do not need authentication, authorization,
>>>>> additional
>>>>> exception handling and checks or schema checking on re-entry instead of
>>>>> having a direct list of interceptors to avoid.
>>>>>
>>>>>  That's a good idea.
>>>>
>>>> One thing that might be problematic though is that we have no idea which
>>>> interceptors are going to be present in the chain, so we may be unable
>>>> to
>>>> tell the chain not to use the interceptors added on the fly (for
>>>> instance,
>>>> the logger interceptor).
>>>>
>>>>
>>>>  Good point. Perhaps this is where we can have some kind of generic
>>> property
>>> that states whether or not by default on re-entry the interceptor should
>>> be
>>> included or excluded. There's a system default, say exclude by default
>>> always. Then the interceptor might override this with some class property
>>> like excludeOnReentry?
>>>
>>> This way even though the IC does not know which interceptors are present
>>> it
>>> can react accordingly on reentry. So for this logger interceptor example
>>> it
>>> might have excludeOnReentry set to false in which case it will always be
>>> included when present which makes send. We would not add the interceptor
>>> if
>>> we did not want to log reentrant invocations.
>>>
>>
> IMO, the best would be to declare sets of (I) we should go through, instead
> of sets of (I) we should bypass. This way, we will be able to know what is
> being executed, and we won't provide a way for users to pollute the internal
> executions of operations (keep in mind that those internal operation are
> themselves called by other operations).
>
> We can also declare those sets in the configuration, for each operation, so
> if we want to allow someone to modify the execution order, it's still
> possible to do so. (it can be done later though).
>

Perhaps we should break this out and discuss this in a separate thread. The
reason historically for listing what you should not execute was a poor
attempt to decouple and well you just don't know what extra interceptors you
have.

I have some ideas here that I also want to think through as well then post.


>  <snip/>
>>>
>>> The Interceptors themselves each have a configuration. In this
>>> configuration the Interceptor should expose what aspects it participates
>>> in.
>>> For example FooInterceptor might expose that it participates in the
>>> authentication aspect. This way the IC knows for example in a schema
>>> modification operation that causes re-entry to occur, this aspect is
>>> excluded say during a modify operation since the session is already
>>> authenticated (no need to perform this twice or on each re-entry into the
>>> IC). The FooInterceptor will be bypassed in this case.
>>>
>>>  For all the discussions above i may suggest using OSGI service
>> properties.
>> So we don't statically reference the specific interceptor class, we just
>> get
>> them using OSGI with some filter like
>> (interceptor.type="**AuthenticationInterceptor"). By this way we don't
>> change
>> a code much but we handle the decoupling.
>>
>
> I like that.
>
>
+1


>
>
>>
>>>
>>>  There can also be other hint mechanisms given to the interceptor chain
>>>>> so
>>>>> it
>>>>> can correctly asses which interceptors to include or exclude on
>>>>> re-entry.
>>>>> For example there could be properties exposed for defaults on the
>>>>> interceptor telling the chain always exclude on re-entry etc. There
>>>>> should
>>>>> be some more thought put on this but the present situation as you state
>>>>> sucks where OSGi and pluggability is concerned.
>>>>>
>>>>>  Right. We will try to get OSGi implemented anyway, and once it's done,
>>>> we
>>>> can start thinking about a better mechanism.
>>>>
>>> FYI, i just implemented dynamic Interceptor loading using IPojo. Its a
>>>
>> starter implementation. We can  improve it using the ideas those come out
>> from that mail. But you must now handling interceptor dynamism does not
>> solved the problems. Now i've to solve problems about concurrency.
>> java.util.concurrent classses are acting weird under OSGI.
>>
>
> Let's think about it when we are done with the decoupling. We first have to
> clean up the place before starting building up something new, otherwise we
> might build some castle on sand...
>

Sounds good.

-- 
Best Regards,
-- Alex

Re: [ADS 2.0] OSGi, interceptors

[Emmanuel Lecharny <el...@gmail.com>]

On 10/13/11 3:16 PM, Göktürk Gezer wrote:
> Hi Emmanuel,Alex
>
> I would like to add something to discussion.
> More inline...
>
> On Thu, Oct 13, 2011 at 3:23 PM, Alex Karasulu<ak...@apache.org>  wrote:
>
>>
>> On Thu, Oct 13, 2011 at 3:05 PM, Emmanuel Lécharny<el...@apache.org>wrote:
>>
>>> On 10/13/11 1:44 PM, Alex Karasulu wrote:
>>>
>>>> On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<el...@apache.org>
>>>> **wrote:
>>>>
>>>>   Hi,
>>>>> Göktük asked if there is a way to transform Interceptors to be bundles
>>>>> instead of being statically loaded in core.
>>>>>
>>>> This can be case yes, but i actually wanted them for further
> interceptors. We can keep core interceptors in place. Don't need to separate
> them all. Lets keep core interceptors in apacheds-core, and protocol
> specific interceptors in their protocol implementation. And then any other
> interceptor that comes and registers itself through OSGI can be attached to
> DirectoryService's interceptor list.

I'd rather decouple the whole thing. There is no reason for core to 
depend on Interceptors.

>
>>>>> I tried to play around the idea yesterday in the train, and I faced some
>>>>> interesting challenges.
>>>>>
>>>>> o First, many interecptors are doing calls to the chain again, but with
>>>>> a
>>>>> restricted set of interceptors. For instance, in the SchemaInterceptor,
>>>>> we
>>>>> go through the chain again when modifying the schema itself. In order to
>>>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
>>>>> sure it's a good idea, but right now, this is how we proceed). At the
>>>>> end,
>>>>> this BYPASS set is declared this way :
>>>>>
>>>>>     private static final Collection<String>   BYPASS;
>>>>>
>>>>>     static
>>>>>     {
>>>>>         Set<String>   c = new HashSet<String>();
>>>>>         c.add( AuthenticationInterceptor.****class.getName() );
>>>>>         c.add( AciAuthorizationInterceptor.****class.getName() );
>>>>>         c.add( DefaultAuthorizationIntercepto****r.class.getName() );
>>>>>         c.add( ExceptionInterceptor.class.****getName() );
>>>>>         c.add( SchemaInterceptor.class.****getName() );
>>>>>         BYPASS = Collections.****unmodifiableCollection( c );
>>>>>
>>>>>     }
>>>>>
>>>>> As we can see, it creates a static dependency on interceptors. It might
>>>>> be
>>>>> a better idea to use logical names instead of class names, and let the
>>>>> OSGi
>>>>> container retrieve the classes itself.
>>>>>
>>>>>
>>>>>   This is a good idea. How about going a little further and having a set
>>>> of
>>>> interceptor chain re-entry constants or set of enum values like:
>>>>
>>>> ReEntry.NO_AUTHENTICATION
>>>> ReEntry.NO_AUTHORIZATION
>>>> ReEntry.NO_ERROR_CHECKING
>>>> ReEntry.NO_SCHEMA_CHECKING
>>>>
>>>> etc ...
>>>>
>>>> This is like saying we do not need authentication, authorization,
>>>> additional
>>>> exception handling and checks or schema checking on re-entry instead of
>>>> having a direct list of interceptors to avoid.
>>>>
>>> That's a good idea.
>>>
>>> One thing that might be problematic though is that we have no idea which
>>> interceptors are going to be present in the chain, so we may be unable to
>>> tell the chain not to use the interceptors added on the fly (for instance,
>>> the logger interceptor).
>>>
>>>
>> Good point. Perhaps this is where we can have some kind of generic property
>> that states whether or not by default on re-entry the interceptor should be
>> included or excluded. There's a system default, say exclude by default
>> always. Then the interceptor might override this with some class property
>> like excludeOnReentry?
>>
>> This way even though the IC does not know which interceptors are present it
>> can react accordingly on reentry. So for this logger interceptor example it
>> might have excludeOnReentry set to false in which case it will always be
>> included when present which makes send. We would not add the interceptor if
>> we did not want to log reentrant invocations.

IMO, the best would be to declare sets of (I) we should go through, 
instead of sets of (I) we should bypass. This way, we will be able to 
know what is being executed, and we won't provide a way for users to 
pollute the internal executions of operations (keep in mind that those 
internal operation are themselves called by other operations).

We can also declare those sets in the configuration, for each operation, 
so if we want to allow someone to modify the execution order, it's still 
possible to do so. (it can be done later though).
>> <snip/>
>> The Interceptors themselves each have a configuration. In this
>> configuration the Interceptor should expose what aspects it participates in.
>> For example FooInterceptor might expose that it participates in the
>> authentication aspect. This way the IC knows for example in a schema
>> modification operation that causes re-entry to occur, this aspect is
>> excluded say during a modify operation since the session is already
>> authenticated (no need to perform this twice or on each re-entry into the
>> IC). The FooInterceptor will be bypassed in this case.
>>
> For all the discussions above i may suggest using OSGI service properties.
> So we don't statically reference the specific interceptor class, we just get
> them using OSGI with some filter like
> (interceptor.type="AuthenticationInterceptor"). By this way we don't change
> a code much but we handle the decoupling.

I like that.

>
>>
>>
>>>> There can also be other hint mechanisms given to the interceptor chain so
>>>> it
>>>> can correctly asses which interceptors to include or exclude on re-entry.
>>>> For example there could be properties exposed for defaults on the
>>>> interceptor telling the chain always exclude on re-entry etc. There
>>>> should
>>>> be some more thought put on this but the present situation as you state
>>>> sucks where OSGi and pluggability is concerned.
>>>>
>>> Right. We will try to get OSGi implemented anyway, and once it's done, we
>>> can start thinking about a better mechanism.
>> FYI, i just implemented dynamic Interceptor loading using IPojo. Its a
> starter implementation. We can  improve it using the ideas those come out
> from that mail. But you must now handling interceptor dynamism does not
> solved the problems. Now i've to solve problems about concurrency.
> java.util.concurrent classses are acting weird under OSGI.

Let's think about it when we are done with the decoupling. We first have 
to clean up the place before starting building up something new, 
otherwise we might build some castle on sand...

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

Re: [ADS 2.0] OSGi, interceptors

[Göktürk Gezer <go...@gmail.com>]

Hi Emmanuel,Alex

I would like to add something to discussion.
More inline...

On Thu, Oct 13, 2011 at 3:23 PM, Alex Karasulu <ak...@apache.org> wrote:

>
>
> On Thu, Oct 13, 2011 at 3:05 PM, Emmanuel Lécharny <el...@apache.org>wrote:
>
>> On 10/13/11 1:44 PM, Alex Karasulu wrote:
>>
>>> On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<el...@apache.org>
>>> **wrote:
>>>
>>>  Hi,
>>>>
>>>> Göktük asked if there is a way to transform Interceptors to be bundles
>>>> instead of being statically loaded in core.
>>>>
>>> This can be case yes, but i actually wanted them for further
interceptors. We can keep core interceptors in place. Don't need to separate
them all. Lets keep core interceptors in apacheds-core, and protocol
specific interceptors in their protocol implementation. And then any other
interceptor that comes and registers itself through OSGI can be attached to
DirectoryService's interceptor list.

>
>>>>
>>>
>>>> I tried to play around the idea yesterday in the train, and I faced some
>>>> interesting challenges.
>>>>
>>>> o First, many interecptors are doing calls to the chain again, but with
>>>> a
>>>> restricted set of interceptors. For instance, in the SchemaInterceptor,
>>>> we
>>>> go through the chain again when modifying the schema itself. In order to
>>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
>>>> sure it's a good idea, but right now, this is how we proceed). At the
>>>> end,
>>>> this BYPASS set is declared this way :
>>>>
>>>>    private static final Collection<String>  BYPASS;
>>>>
>>>>    static
>>>>    {
>>>>        Set<String>  c = new HashSet<String>();
>>>>        c.add( AuthenticationInterceptor.****class.getName() );
>>>>        c.add( AciAuthorizationInterceptor.****class.getName() );
>>>>        c.add( DefaultAuthorizationIntercepto****r.class.getName() );
>>>>        c.add( ExceptionInterceptor.class.****getName() );
>>>>        c.add( SchemaInterceptor.class.****getName() );
>>>>        BYPASS = Collections.****unmodifiableCollection( c );
>>>>
>>>>    }
>>>>
>>>> As we can see, it creates a static dependency on interceptors. It might
>>>> be
>>>> a better idea to use logical names instead of class names, and let the
>>>> OSGi
>>>> container retrieve the classes itself.
>>>>
>>>>
>>>>  This is a good idea. How about going a little further and having a set
>>> of
>>> interceptor chain re-entry constants or set of enum values like:
>>>
>>> ReEntry.NO_AUTHENTICATION
>>> ReEntry.NO_AUTHORIZATION
>>> ReEntry.NO_ERROR_CHECKING
>>> ReEntry.NO_SCHEMA_CHECKING
>>>
>>> etc ...
>>>
>>> This is like saying we do not need authentication, authorization,
>>> additional
>>> exception handling and checks or schema checking on re-entry instead of
>>> having a direct list of interceptors to avoid.
>>>
>>
>> That's a good idea.
>>
>> One thing that might be problematic though is that we have no idea which
>> interceptors are going to be present in the chain, so we may be unable to
>> tell the chain not to use the interceptors added on the fly (for instance,
>> the logger interceptor).
>>
>>
> Good point. Perhaps this is where we can have some kind of generic property
> that states whether or not by default on re-entry the interceptor should be
> included or excluded. There's a system default, say exclude by default
> always. Then the interceptor might override this with some class property
> like excludeOnReentry?
>
> This way even though the IC does not know which interceptors are present it
> can react accordingly on reentry. So for this logger interceptor example it
> might have excludeOnReentry set to false in which case it will always be
> included when present which makes send. We would not add the interceptor if
> we did not want to log reentrant invocations.
>
>
>> I'd rather create a set of interceptors we want to go through, as we know
>> which one we will use in those internal cases.
>>
>> In any case, using constants instead of class name is the way to go.
>>
>>
> Yes this is definitely the first step, perhaps the final step but perhaps
> you might want to entertain the idea of evaluating inclusion or exclusion
> based on properties. This makes debugging a tiny bit more complicated but it
> gives us a more pluggable way to manage the IC.
>
>
>>
>>> Then Interceptors when they register themselves can announce what
>>> standard
>>> functions they perform according to this set. Some may not announce at
>>> all
>>> if they perform none of these functions. This way the chain determines
>>> what
>>> to include and what to exclude based on these properties. There's no
>>> direct
>>> link with the interceptor itself and any implementation can be swapped in
>>> and out.
>>>
>>> This way we are letting the interceptor chain devise the proper chain of
>>> interceptors based on these properties instead of using more explicit
>>> names
>>> or direct references to the interceptor classes.
>>>
>>
>> Ultimately, for each operation (add, delete, lookup, etc), we should be
>> able to define the set of interceptors we are going through.
>
>
> My thinking is to not define things in terms of interceptors to go through
> or not go through for each operation but rather we should define the aspects
> to include or exclude on re-entry into the IC for each operation. Keeping it
> generic this way, and having the Interceptor tell the IC which aspects it
> participates in allows the IC to include or exclude on re-entry.
>
>
>> This should be defined somewhere in the code, not in each interceptors. It
>> may even be some configurable information...
>>
>>
> I see two points of configuration.
>
> One configuration is the IC configuration it self which includes the
> aspects to include or exclude on re-entry for each of the add, delete,
> lookup etc operations. The IC itself is a component with this perspective.
>
> The Interceptors themselves each have a configuration. In this
> configuration the Interceptor should expose what aspects it participates in.
> For example FooInterceptor might expose that it participates in the
> authentication aspect. This way the IC knows for example in a schema
> modification operation that causes re-entry to occur, this aspect is
> excluded say during a modify operation since the session is already
> authenticated (no need to perform this twice or on each re-entry into the
> IC). The FooInterceptor will be bypassed in this case.
>
For all the discussions above i may suggest using OSGI service properties.
So we don't statically reference the specific interceptor class, we just get
them using OSGI with some filter like
(interceptor.type="AuthenticationInterceptor"). By this way we don't change
a code much but we handle the decoupling.

>
>
>
>>
>>> There can also be other hint mechanisms given to the interceptor chain so
>>> it
>>> can correctly asses which interceptors to include or exclude on re-entry.
>>> For example there could be properties exposed for defaults on the
>>> interceptor telling the chain always exclude on re-entry etc. There
>>> should
>>> be some more thought put on this but the present situation as you state
>>> sucks where OSGi and pluggability is concerned.
>>>
>> Right. We will try to get OSGi implemented anyway, and once it's done, we
>> can start thinking about a better mechanism.
>
> FYI, i just implemented dynamic Interceptor loading using IPojo. Its a
starter implementation. We can  improve it using the ideas those come out
from that mail. But you must now handling interceptor dynamism does not
solved the problems. Now i've to solve problems about concurrency.
java.util.concurrent classses are acting weird under OSGI.

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

Re: [ADS 2.0] OSGi, interceptors

[Alex Karasulu <ak...@apache.org>]

On Thu, Oct 13, 2011 at 3:05 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> On 10/13/11 1:44 PM, Alex Karasulu wrote:
>
>> On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<el...@apache.org>*
>> *wrote:
>>
>>  Hi,
>>>
>>> Göktük asked if there is a way to transform Interceptors to be bundles
>>> instead of being statically loaded in core.
>>>
>>> I tried to play around the idea yesterday in the train, and I faced some
>>> interesting challenges.
>>>
>>> o First, many interecptors are doing calls to the chain again, but with a
>>> restricted set of interceptors. For instance, in the SchemaInterceptor,
>>> we
>>> go through the chain again when modifying the schema itself. In order to
>>> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
>>> sure it's a good idea, but right now, this is how we proceed). At the
>>> end,
>>> this BYPASS set is declared this way :
>>>
>>>    private static final Collection<String>  BYPASS;
>>>
>>>    static
>>>    {
>>>        Set<String>  c = new HashSet<String>();
>>>        c.add( AuthenticationInterceptor.****class.getName() );
>>>        c.add( AciAuthorizationInterceptor.****class.getName() );
>>>        c.add( DefaultAuthorizationIntercepto****r.class.getName() );
>>>        c.add( ExceptionInterceptor.class.****getName() );
>>>        c.add( SchemaInterceptor.class.****getName() );
>>>        BYPASS = Collections.****unmodifiableCollection( c );
>>>
>>>    }
>>>
>>> As we can see, it creates a static dependency on interceptors. It might
>>> be
>>> a better idea to use logical names instead of class names, and let the
>>> OSGi
>>> container retrieve the classes itself.
>>>
>>>
>>>  This is a good idea. How about going a little further and having a set
>> of
>> interceptor chain re-entry constants or set of enum values like:
>>
>> ReEntry.NO_AUTHENTICATION
>> ReEntry.NO_AUTHORIZATION
>> ReEntry.NO_ERROR_CHECKING
>> ReEntry.NO_SCHEMA_CHECKING
>>
>> etc ...
>>
>> This is like saying we do not need authentication, authorization,
>> additional
>> exception handling and checks or schema checking on re-entry instead of
>> having a direct list of interceptors to avoid.
>>
>
> That's a good idea.
>
> One thing that might be problematic though is that we have no idea which
> interceptors are going to be present in the chain, so we may be unable to
> tell the chain not to use the interceptors added on the fly (for instance,
> the logger interceptor).
>
>
Good point. Perhaps this is where we can have some kind of generic property
that states whether or not by default on re-entry the interceptor should be
included or excluded. There's a system default, say exclude by default
always. Then the interceptor might override this with some class property
like excludeOnReentry?

This way even though the IC does not know which interceptors are present it
can react accordingly on reentry. So for this logger interceptor example it
might have excludeOnReentry set to false in which case it will always be
included when present which makes send. We would not add the interceptor if
we did not want to log reentrant invocations.


> I'd rather create a set of interceptors we want to go through, as we know
> which one we will use in those internal cases.
>
> In any case, using constants instead of class name is the way to go.
>
>
Yes this is definitely the first step, perhaps the final step but perhaps
you might want to entertain the idea of evaluating inclusion or exclusion
based on properties. This makes debugging a tiny bit more complicated but it
gives us a more pluggable way to manage the IC.


>
>> Then Interceptors when they register themselves can announce what standard
>> functions they perform according to this set. Some may not announce at all
>> if they perform none of these functions. This way the chain determines
>> what
>> to include and what to exclude based on these properties. There's no
>> direct
>> link with the interceptor itself and any implementation can be swapped in
>> and out.
>>
>> This way we are letting the interceptor chain devise the proper chain of
>> interceptors based on these properties instead of using more explicit
>> names
>> or direct references to the interceptor classes.
>>
>
> Ultimately, for each operation (add, delete, lookup, etc), we should be
> able to define the set of interceptors we are going through.


My thinking is to not define things in terms of interceptors to go through
or not go through for each operation but rather we should define the aspects
to include or exclude on re-entry into the IC for each operation. Keeping it
generic this way, and having the Interceptor tell the IC which aspects it
participates in allows the IC to include or exclude on re-entry.


> This should be defined somewhere in the code, not in each interceptors. It
> may even be some configurable information...
>
>
I see two points of configuration.

One configuration is the IC configuration it self which includes the aspects
to include or exclude on re-entry for each of the add, delete, lookup etc
operations. The IC itself is a component with this perspective.

The Interceptors themselves each have a configuration. In this configuration
the Interceptor should expose what aspects it participates in. For example
FooInterceptor might expose that it participates in the authentication
aspect. This way the IC knows for example in a schema modification operation
that causes re-entry to occur, this aspect is excluded say during a modify
operation since the session is already authenticated (no need to perform
this twice or on each re-entry into the IC). The FooInterceptor will be
bypassed in this case.



>
>> There can also be other hint mechanisms given to the interceptor chain so
>> it
>> can correctly asses which interceptors to include or exclude on re-entry.
>> For example there could be properties exposed for defaults on the
>> interceptor telling the chain always exclude on re-entry etc. There should
>> be some more thought put on this but the present situation as you state
>> sucks where OSGi and pluggability is concerned.
>>
> Right. We will try to get OSGi implemented anyway, and once it's done, we
> can start thinking about a better mechanism.
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Best Regards,
-- Alex

Re: [ADS 2.0] OSGi, interceptors

[Emmanuel Lécharny <el...@apache.org>]

On 10/13/11 1:44 PM, Alex Karasulu wrote:
> On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny<el...@apache.org>wrote:
>
>> Hi,
>>
>> Göktük asked if there is a way to transform Interceptors to be bundles
>> instead of being statically loaded in core.
>>
>> I tried to play around the idea yesterday in the train, and I faced some
>> interesting challenges.
>>
>> o First, many interecptors are doing calls to the chain again, but with a
>> restricted set of interceptors. For instance, in the SchemaInterceptor, we
>> go through the chain again when modifying the schema itself. In order to
>> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
>> sure it's a good idea, but right now, this is how we proceed). At the end,
>> this BYPASS set is declared this way :
>>
>>     private static final Collection<String>  BYPASS;
>>
>>     static
>>     {
>>         Set<String>  c = new HashSet<String>();
>>         c.add( AuthenticationInterceptor.**class.getName() );
>>         c.add( AciAuthorizationInterceptor.**class.getName() );
>>         c.add( DefaultAuthorizationIntercepto**r.class.getName() );
>>         c.add( ExceptionInterceptor.class.**getName() );
>>         c.add( SchemaInterceptor.class.**getName() );
>>         BYPASS = Collections.**unmodifiableCollection( c );
>>     }
>>
>> As we can see, it creates a static dependency on interceptors. It might be
>> a better idea to use logical names instead of class names, and let the OSGi
>> container retrieve the classes itself.
>>
>>
> This is a good idea. How about going a little further and having a set of
> interceptor chain re-entry constants or set of enum values like:
>
> ReEntry.NO_AUTHENTICATION
> ReEntry.NO_AUTHORIZATION
> ReEntry.NO_ERROR_CHECKING
> ReEntry.NO_SCHEMA_CHECKING
>
> etc ...
>
> This is like saying we do not need authentication, authorization, additional
> exception handling and checks or schema checking on re-entry instead of
> having a direct list of interceptors to avoid.

That's a good idea.

One thing that might be problematic though is that we have no idea which 
interceptors are going to be present in the chain, so we may be unable 
to tell the chain not to use the interceptors added on the fly (for 
instance, the logger interceptor).

I'd rather create a set of interceptors we want to go through, as we 
know which one we will use in those internal cases.

In any case, using constants instead of class name is the way to go.
>
> Then Interceptors when they register themselves can announce what standard
> functions they perform according to this set. Some may not announce at all
> if they perform none of these functions. This way the chain determines what
> to include and what to exclude based on these properties. There's no direct
> link with the interceptor itself and any implementation can be swapped in
> and out.
>
> This way we are letting the interceptor chain devise the proper chain of
> interceptors based on these properties instead of using more explicit names
> or direct references to the interceptor classes.

Ultimately, for each operation (add, delete, lookup, etc), we should be 
able to define the set of interceptors we are going through. This should 
be defined somewhere in the code, not in each interceptors. It may even 
be some configurable information...
>
> There can also be other hint mechanisms given to the interceptor chain so it
> can correctly asses which interceptors to include or exclude on re-entry.
> For example there could be properties exposed for defaults on the
> interceptor telling the chain always exclude on re-entry etc. There should
> be some more thought put on this but the present situation as you state
> sucks where OSGi and pluggability is concerned.
Right. We will try to get OSGi implemented anyway, and once it's done, 
we can start thinking about a better mechanism.


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

Re: [ADS 2.0] OSGi, interceptors

[Alex Karasulu <ak...@apache.org>]

On Thu, Oct 13, 2011 at 2:20 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> Hi,
>
> Göktük asked if there is a way to transform Interceptors to be bundles
> instead of being statically loaded in core.
>
> I tried to play around the idea yesterday in the train, and I faced some
> interesting challenges.
>
> o First, many interecptors are doing calls to the chain again, but with a
> restricted set of interceptors. For instance, in the SchemaInterceptor, we
> go through the chain again when modifying the schema itself. In order to
> speedup the operation, we declare a BYPASS sets of interceptors (I'm not
> sure it's a good idea, but right now, this is how we proceed). At the end,
> this BYPASS set is declared this way :
>
>    private static final Collection<String> BYPASS;
>
>    static
>    {
>        Set<String> c = new HashSet<String>();
>        c.add( AuthenticationInterceptor.**class.getName() );
>        c.add( AciAuthorizationInterceptor.**class.getName() );
>        c.add( DefaultAuthorizationIntercepto**r.class.getName() );
>        c.add( ExceptionInterceptor.class.**getName() );
>        c.add( SchemaInterceptor.class.**getName() );
>        BYPASS = Collections.**unmodifiableCollection( c );
>    }
>
> As we can see, it creates a static dependency on interceptors. It might be
> a better idea to use logical names instead of class names, and let the OSGi
> container retrieve the classes itself.
>
>
This is a good idea. How about going a little further and having a set of
interceptor chain re-entry constants or set of enum values like:

ReEntry.NO_AUTHENTICATION
ReEntry.NO_AUTHORIZATION
ReEntry.NO_ERROR_CHECKING
ReEntry.NO_SCHEMA_CHECKING

etc ...

This is like saying we do not need authentication, authorization, additional
exception handling and checks or schema checking on re-entry instead of
having a direct list of interceptors to avoid.

Then Interceptors when they register themselves can announce what standard
functions they perform according to this set. Some may not announce at all
if they perform none of these functions. This way the chain determines what
to include and what to exclude based on these properties. There's no direct
link with the interceptor itself and any implementation can be swapped in
and out.

This way we are letting the interceptor chain devise the proper chain of
interceptors based on these properties instead of using more explicit names
or direct references to the interceptor classes.

There can also be other hint mechanisms given to the interceptor chain so it
can correctly asses which interceptors to include or exclude on re-entry.
For example there could be properties exposed for defaults on the
interceptor telling the chain always exclude on re-entry etc. There should
be some more thought put on this but the present situation as you state
sucks where OSGi and pluggability is concerned.


> o Second, we have places in core were we call the interceptors, like in
> DefaultDirectoryService :
>
>    public boolean isPwdPolicyEnabled()
>    {
>        AuthenticationInterceptor authenticationInterceptor =
> (AuthenticationInterceptor)**getInterceptor( AuthenticationInterceptor.**class.getName()
> );
>        if ( authenticationInterceptor == null )
>        {
>            return false;
>        }
>
>        PpolicyConfigContainer pwdPolicyContainer =
> authenticationInterceptor.**getPwdPolicyContainer();
>
>        return ( ( pwdPolicyContainer != null )
> && ( ( pwdPolicyContainer.**getDefaultPolicy() != null )
>                || ( pwdPolicyContainer.**hasCustomConfigs() ) ) );
>    }
>
> I'm quite sure we should do that in anothr way...
>
>
>
Yes this is causing unnecessary coupling between interceptors.


>
> Right, now, I'm experimenting, moving each interceptors into a dedicated
> project (under apacheds/interceptors/authn, ...) to see what are the
> impacts.


Good idea this should clean things up and show us clearly what the cross
interceptor dependencies are.


> I'll come back with some more informations when I'll have a clear vision
> about the impacts.
>
>
Thank you,
Alex

[ADS 2.0] OSGi, interceptors

[Emmanuel Lécharny <el...@apache.org>]

Hi,

Göktük asked if there is a way to transform Interceptors to be bundles 
instead of being statically loaded in core.

I tried to play around the idea yesterday in the train, and I faced some 
interesting challenges.

o First, many interecptors are doing calls to the chain again, but with 
a restricted set of interceptors. For instance, in the 
SchemaInterceptor, we go through the chain again when modifying the 
schema itself. In order to speedup the operation, we declare a BYPASS 
sets of interceptors (I'm not sure it's a good idea, but right now, this 
is how we proceed). At the end, this BYPASS set is declared this way :

     private static final Collection<String> BYPASS;

     static
     {
         Set<String> c = new HashSet<String>();
         c.add( AuthenticationInterceptor.class.getName() );
         c.add( AciAuthorizationInterceptor.class.getName() );
         c.add( DefaultAuthorizationInterceptor.class.getName() );
         c.add( ExceptionInterceptor.class.getName() );
         c.add( SchemaInterceptor.class.getName() );
         BYPASS = Collections.unmodifiableCollection( c );
     }

As we can see, it creates a static dependency on interceptors. It might 
be a better idea to use logical names instead of class names, and let 
the OSGi container retrieve the classes itself.

o Second, we have places in core were we call the interceptors, like in 
DefaultDirectoryService :

     public boolean isPwdPolicyEnabled()
     {
         AuthenticationInterceptor authenticationInterceptor = 
(AuthenticationInterceptor)getInterceptor( 
AuthenticationInterceptor.class.getName() );
         if ( authenticationInterceptor == null )
         {
             return false;
         }

         PpolicyConfigContainer pwdPolicyContainer = 
authenticationInterceptor.getPwdPolicyContainer();

         return ( ( pwdPolicyContainer != null )
&& ( ( pwdPolicyContainer.getDefaultPolicy() != null )
                 || ( pwdPolicyContainer.hasCustomConfigs() ) ) );
     }

I'm quite sure we should do that in anothr way...



Right, now, I'm experimenting, moving each interceptors into a dedicated 
project (under apacheds/interceptors/authn, ...) to see what are the 
impacts. I'll come back with some more informations when I'll have a 
clear vision about the impacts.

Tahnks !

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

Re: [ADS 2.0] OSGi : solving package conflicts

[Göktürk Gezer <go...@gmail.com>]

Hi Stefan,

Thank you for that. I would create a patch but, it is still not the best
way. I'm waiting for you then.

Regards,
Gokturk

On Sun, Oct 9, 2011 at 7:39 PM, Stefan Seelmann <se...@apache.org> wrote:

> Hi Göktürk,
>
> I agree that it doesn't make sense to rename packages as a
> non-committer. When applying the patch only the contents of the files
> would be move but SVN history would get lost. I'll try to redo your
> changes and give feedback.
>
> Kind Regards,
> Stefan

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

Hi Göktürk,

I agree that it doesn't make sense to rename packages as a
non-committer. When applying the patch only the contents of the files
would be move but SVN history would get lost. I'll try to redo your
changes and give feedback.

Kind Regards,
Stefan


On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com> wrote:
> Hi,
> I attached a patch that solves these package conflicts. But i'm still unsure
> about working on trunk.Package renamings are something hard to describe as
> diff. Right now, this diff zeroes the old package contents, add new ones and
> modify other parts of code to use new packages. i can also create a script
> to make your local copy consistent after patch, and then you can commit like
> that. So, guide me to the correct way of doing it.
> Here is a change list:
> /org/apache/directory/server ./apacheds/http-directory-bridge
> -> changed to /org/apache/directory/server/bridge/http
> /org/apache/directory/server ./apacheds/service
> /org/apache/directory/server ./apacheds/wrapper ->
> /org/apache/directory/server/wrapper
> -> changed as suggested
> ------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/server/config ./apacheds/server-config
> /org/apache/directory/server/config ./apacheds/service-builder ->
> /org/apache/directory/server/config/builder
> /org/apache/directory/server/core ./apacheds/core
> /org/apache/directory/server/core ./apacheds/core-api ->
> /org/apache/directory/server/core/api
> /org/apache/directory/server/core/changelog ./apacheds/core
> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
> /org/apache/directory/server/core/api/changelog
> /org/apache/directory/server/core/event ./apacheds/core
> /org/apache/directory/server/core/event ./apacheds/core-api ->
> /org/apache/directory/server/core/api/event
> /org/apache/directory/server/core/interceptor ./apacheds/core
> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
> /org/apache/directory/server/core/api/interceptor
> /org/apache/directory/server/core/journal ./apacheds/core
> /org/apache/directory/server/core/journal ./apacheds/core-api ->
> /org/apache/directory/server/core/api/journal
> /org/apache/directory/server/core/partition ./apacheds/core
> /org/apache/directory/server/core/partition ./apacheds/core-api ->
> /org/apache/directory/server/core/api/partition
> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
> /org/apache/directory/server/core/partition/impl
> -> was test package, changed to
> /org/apache/directory/server/core/partition/ldif
> /org/apache/directory/server/core/replication ./apacheds/core
> /org/apache/directory/server/core/replication ./apacheds/core-api ->
> /org/apache/directory/server/core/api/replication
> /org/apache/directory/server/core/schema ./apacheds/core
> /org/apache/directory/server/core/schema ./apacheds/core-api ->
> /org/apache/directory/server/core/api/schema
> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
> /org/apache/directory/server/core/schema/jdbm
> -> was test package, changed as suggested.
>
> -> All packages(source and test) under apacheds-api is moved into
> org/apache/directory/server/core/api package
> -> DefaultPartitionNexus class is moved from apacheds-core to
> apacheds-core-api to defeat cyclic builds
> --------------------------------------------------------------------------------------------------------------------------
> This is not a conflict (test) :
> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
> ---------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec ->
> /org/apache/directory/server/kerberos/protocol/codec
> -> changed as suggested
> /org/apache/directory/server/kerberos/protocol ./apacheds/protocol-kerberos
> ------------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/server/ldap/handlers/extended ./apacheds/protocol-ldap
> /org/apache/directory/server/ldap/handlers/extended ./apacheds/server-tools
> -> /org/apache/directory/server/ldap/handlers/extended/tools
> -> server-tools project was out of the build. left untouched
> --------------------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/standalone
> -> /org/apache/directory/shared/ldap/codec/osgi/standalone
> -> was test package, changed as suggested
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec ->
> /org/apache/directory/shared/ldap/codec/osgi/extras
> -> was test package, changed as suggested
> -----------------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/shared/ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec
> /org/apache/directory/shared/ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec-api ->
> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
> -> changed as suggested
> Regards,
> Gokturk

Re: [ADS 2.0] OSGi : solving package conflicts

[Göktürk Gezer <go...@gmail.com>]

Patch to package conflicts.

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

> Packages are fine now, thanks. About core-api, Emmanuel thinks the same, moving all packages org.apache.directory.server.core.api parent.

Done

> Package renamings have broken the apacheds-service BTW. Its Just a harcoded class name. diff to fix attached.

Thanks for the patch, applied to trunk.

Re: [ADS 2.0] OSGi : solving package conflicts

[Göktürk Gezer <go...@gmail.com>]

Hi Stefan,

Packages are fine now, thanks. About core-api, Emmanuel thinks the same,
moving all packages org.apache.directory.server.core.api parent.

Package renamings have broken the apacheds-service BTW. Its Just a harcoded
class name. diff to fix attached.


Regards,
Gokturk

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

On Sun, Oct 9, 2011 at 10:55 PM, Stefan Seelmann <se...@apache.org>wrote:

> On Sun, Oct 9, 2011 at 9:02 PM, Stefan Seelmann <se...@apache.org>wrote:
>
>> On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com>wrote:
>>
>>> Hi,
>>> I attached a patch that solves these package conflicts. But i'm still
>>> unsure about working on trunk.Package renamings are something hard to
>>> describe as diff. Right now, this diff zeroes the old package contents, add
>>> new ones and modify other parts of code to use new packages. i can also
>>> create a script to make your local copy consistent after patch, and then you
>>> can commit like that. So, guide me to the correct way of doing it.
>>>
>>> Here is a change list:
>>>
>>> /org/apache/directory/server ./apacheds/http-directory-bridge
>>> -> changed to /org/apache/directory/server/bridge/http
>>>
>>
>> done
>>
>>
>>> /org/apache/directory/server ./apacheds/service
>>>
>>> /org/apache/directory/server ./apacheds/wrapper ->
>>> /org/apache/directory/server/wrapper
>>> -> changed as suggested
>>>
>>
>> done
>> also changed reference to ApacheDsTanukiWrapper in
>> installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/wrapper-installation.conf
>>
>>
>>>
>>> /org/apache/directory/server/config ./apacheds/server-config
>>> /org/apache/directory/server/config ./apacheds/service-builder ->
>>> /org/apache/directory/server/config/builder
>>>
>>
>> done
>>
>> I committed the previous changes. The next changes are a bit more tricky
>> as those guys are also used in Studio.
>>
>>
>>> /org/apache/directory/server/core ./apacheds/core
>>> /org/apache/directory/server/core ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api
>>>
>>
> done
> Made CacheService constructor public. Should this class be moved to
> apacheds-core?
>
>
>>  /org/apache/directory/server/core/changelog ./apacheds/core
>>> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/changelog
>>>
>>
> done
>
>  /org/apache/directory/server/core/event ./apacheds/core
>>> /org/apache/directory/server/core/event ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/event
>>>
>>
> done
> Made RegistrationEntry constructor and method public.
>
>
>> /org/apache/directory/server/core/interceptor ./apacheds/core
>>> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/interceptor
>>>
>>
> done, including interceptor.context package
>
>
>> /org/apache/directory/server/core/journal ./apacheds/core
>>>
>>  /org/apache/directory/server/core/journal ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/journal
>>>
>>
> done
>
>  /org/apache/directory/server/core/partition ./apacheds/core
>>> /org/apache/directory/server/core/partition ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/partition
>>>
>> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
>>> /org/apache/directory/server/core/partition/impl
>>> -> was test package, changed to
>>> /org/apache/directory/server/core/partition/ldif
>>>
>>
> done, good catch with the test package
>
>  /org/apache/directory/server/core/replication ./apacheds/core
>>> /org/apache/directory/server/core/replication ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/replication
>>>
>>
> Can't find this package, has this been moved before?
>
>  /org/apache/directory/server/core/schema ./apacheds/core
>>> /org/apache/directory/server/core/schema ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/schema
>>>
>>
> done, but the classes in that package should be reviews and eventually
> moved to apacheds-core
>
> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
>>> /org/apache/directory/server/core/schema/jdbm
>>>
>>
> Moved PartitionSchemaLoaderTest from jdbm-partition to core-integ as
> described in a TODO within that class, removed the package.
>
>
>  -> All packages(source and test) under apacheds-api is moved into
>>> org/apache/directory/server/core/api package
>>>
>>
> Do you mean you renamed all packages even those that are not conflicting? I
> didn't renamed those in the first step but I agree that it makes sense to do
> so. However before that we should review if those packages belong to the
> "api" module. The remaining packages are
> - org.apache.directory.server.core.administrative
> - org.apache.directory.server.core.entry
> - org.apache.directory.server.core.filtering
> - org.apache.directory.server.core.invocation
> - org.apache.directory.server.core.schema.registries.synchronizers
>
>
>>  -> DefaultPartitionNexus class is moved from apacheds-core to
>>> apacheds-core-api to defeat cyclic builds
>>>
>>
> That was not required, there were just unused imports that I deleted.
>
>
> When I run the test I saw that LdapConnectionFactory (in
> shared-ldap-client-api) has a method getCoreSessionConnection() the creates
> an instance of LdapCoreSessionConnection via reflection. IMO this should be
> moved to some ApacheDS module.
>
> Committed so far.
>
>
>>> --------------------------------------------------------------------------------------------------------------------------
>>> This is not a conflict (test) :
>>> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
>>> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------
>>> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
>>> -> /org/apache/directory/server/kerberos/protocol/codec
>>> -> changed as suggested
>>> /org/apache/directory/server/kerberos/protocol
>>> ./apacheds/protocol-kerberos
>>>
>>
done


>
>>> ------------------------------------------------------------------------------------------------------------------------------
>>>  /org/apache/directory/server/ldap/handlers/extended
>>> ./apacheds/protocol-ldap
>>> /org/apache/directory/server/ldap/handlers/extended
>>> ./apacheds/server-tools ->
>>> /org/apache/directory/server/ldap/handlers/extended/tools
>>> -> server-tools project was out of the build. left untouched
>>>
>>> --------------------------------------------------------------------------------------------------------------------------------------
>>>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
>>> /org/apache/directory/shared/ldap/codec/osgi
>>> ./shared/ldap/codec/standalone ->
>>> /org/apache/directory/shared/ldap/codec/osgi/standalone
>>> -> was test package, changed as suggested
>>>
>>
Renamed to /org/apache/directory/shared/ldap/codec/standalone, same as the
main package. But the only test  there (AbstractCodecServiceTest) is
abstract and there is no subclass so makes not really sense to keep that
class or can we create another real test?

Also deleted package org.apache.directory.shared.ldap.codec.controls and
class OpaqueControlTest as the same test is already in shared-ldap-model.


>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec
>>> -> /org/apache/directory/shared/ldap/codec/osgi/extras
>>> -> was test package, changed as suggested
>>>
>>
Renamed to /org/apache/directory/shared/ldap/extras, same as the main
package name.
Made DefaultLdapCodecService() constructor public.


>
>>> -----------------------------------------------------------------------------------------------------------------------------------
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>> ./shared/ldap/extras/codec
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>> ./shared/ldap/extras/codec-api ->
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
>>>
>>
Rather renamed the package in shared/ldap/extras/codec ->
/org/apache/directory/shared/ldap/extras/controls/ppolicy_impl to be
consistent with the other package names in that module.


I hope that's all, except the remaining package names in core-api. If I
forgot something please ping me.

Kind Regards,
Stefan

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

I wasn't able to commit the remaining stuff this morning because I have test
failures. I'll continue later tonight.

Kind Regards,
Stefan


On Sun, Oct 9, 2011 at 11:30 PM, Göktürk Gezer <go...@gmail.com>wrote:

>
>
> On Sun, Oct 9, 2011 at 11:55 PM, Stefan Seelmann <se...@apache.org>wrote:
>
>>
>>
>> On Sun, Oct 9, 2011 at 9:02 PM, Stefan Seelmann <se...@apache.org>wrote:
>>
>>> On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com>wrote:
>>>
>>>> Hi,
>>>> I attached a patch that solves these package conflicts. But i'm still
>>>> unsure about working on trunk.Package renamings are something hard to
>>>> describe as diff. Right now, this diff zeroes the old package contents, add
>>>> new ones and modify other parts of code to use new packages. i can also
>>>> create a script to make your local copy consistent after patch, and then you
>>>> can commit like that. So, guide me to the correct way of doing it.
>>>>
>>>> Here is a change list:
>>>>
>>>> /org/apache/directory/server ./apacheds/http-directory-bridge
>>>> -> changed to /org/apache/directory/server/bridge/http
>>>>
>>>
>>> done
>>>
>>>
>>>> /org/apache/directory/server ./apacheds/service
>>>>
>>>> /org/apache/directory/server ./apacheds/wrapper ->
>>>> /org/apache/directory/server/wrapper
>>>> -> changed as suggested
>>>>
>>>
>>> done
>>> also changed reference to ApacheDsTanukiWrapper in
>>> installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/wrapper-installation.conf
>>>
>>>
>>>>
>>>> /org/apache/directory/server/config ./apacheds/server-config
>>>> /org/apache/directory/server/config ./apacheds/service-builder ->
>>>> /org/apache/directory/server/config/builder
>>>>
>>>
>>> done
>>>
>>> I committed the previous changes. The next changes are a bit more tricky
>>> as those guys are also used in Studio.
>>>
>>>
>>>> /org/apache/directory/server/core ./apacheds/core
>>>> /org/apache/directory/server/core ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api
>>>>
>>>
>> done
>> Made CacheService constructor public. Should this class be moved to
>> apacheds-core?
>>
> i found no beneficial usage for it on apacheds-core-api.
>
>>
>>
>>>  /org/apache/directory/server/core/changelog ./apacheds/core
>>>> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/changelog
>>>>
>>>
>> done
>>
>>  /org/apache/directory/server/core/event ./apacheds/core
>>>> /org/apache/directory/server/core/event ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/event
>>>>
>>>
>> done
>> Made RegistrationEntry constructor and method public.
>>
> I was cautios about contructor visibilities, but they're necessary. I hope
> they're not meant to be privite.
>
>>
>>
>>> /org/apache/directory/server/core/interceptor ./apacheds/core
>>>> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/interceptor
>>>>
>>>
>> done, including interceptor.context package
>>
>>
>>> /org/apache/directory/server/core/journal ./apacheds/core
>>>>
>>>  /org/apache/directory/server/core/journal ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/journal
>>>>
>>>
>> done
>>
>>  /org/apache/directory/server/core/partition ./apacheds/core
>>>> /org/apache/directory/server/core/partition ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/partition
>>>>
>>> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
>>>> /org/apache/directory/server/core/partition/impl
>>>> -> was test package, changed to
>>>> /org/apache/directory/server/core/partition/ldif
>>>>
>>>
>> done, good catch with the test package
>>
>>  /org/apache/directory/server/core/replication ./apacheds/core
>>>> /org/apache/directory/server/core/replication ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/replication
>>>>
>>>
>> Can't find this package, has this been moved before?
>>
> Yes i guess, i couldn't find it too.
>
>>
>>  /org/apache/directory/server/core/schema ./apacheds/core
>>>> /org/apache/directory/server/core/schema ./apacheds/core-api ->
>>>> /org/apache/directory/server/core/api/schema
>>>>
>>>
>> done, but the classes in that package should be reviews and eventually
>> moved to apacheds-core
>>
>> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
>>>> /org/apache/directory/server/core/schema/jdbm
>>>>
>>>
>> Moved PartitionSchemaLoaderTest from jdbm-partition to core-integ as
>> described in a TODO within that class, removed the package.
>>
>>
>>  -> All packages(source and test) under apacheds-api is moved into
>>>> org/apache/directory/server/core/api package
>>>>
>>>
>> Do you mean you renamed all packages even those that are not conflicting?
>> I didn't renamed those in the first step but I agree that it makes sense to
>> do so. However before that we should review if those packages belong to the
>> "api" module. The remaining packages are
>> - org.apache.directory.server.core.administrative
>> - org.apache.directory.server.core.entry
>> - org.apache.directory.server.core.filtering
>> - org.apache.directory.server.core.invocation
>> - org.apache.directory.server.core.schema.registries.synchronizers
>>
>
> Yes i renamed all even if they're not conflicting. It seems neater to me.
>
>>
>>
>>>  -> DefaultPartitionNexus class is moved from apacheds-core to
>>>> apacheds-core-api to defeat cyclic builds
>>>>
>>>
>> That was not required, there were just unused imports that I deleted.
>>
> Yeah, that's better. I didn't look closely at how it's used in core-api.
>
>>
>>
>> When I run the test I saw that LdapConnectionFactory (in
>> shared-ldap-client-api) has a method getCoreSessionConnection() the creates
>> an instance of LdapCoreSessionConnection via reflection. IMO this should be
>> moved to some ApacheDS module.
>>
> I handled that by just renaming that package name to its new name. This
> class is being heavily used by ApacheDS modules for testing, having it in
> some ApacheDS module means more.
>
>>
>> Committed so far.
>>
>
> Thanks.
>
>
>>
>>
>>>> --------------------------------------------------------------------------------------------------------------------------
>>>> This is not a conflict (test) :
>>>> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
>>>> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
>>>>
>>>> ---------------------------------------------------------------------------------------------------------------------------
>>>> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
>>>> -> /org/apache/directory/server/kerberos/protocol/codec
>>>> -> changed as suggested
>>>> /org/apache/directory/server/kerberos/protocol
>>>> ./apacheds/protocol-kerberos
>>>>
>>>> ------------------------------------------------------------------------------------------------------------------------------
>>>>  /org/apache/directory/server/ldap/handlers/extended
>>>> ./apacheds/protocol-ldap
>>>> /org/apache/directory/server/ldap/handlers/extended
>>>> ./apacheds/server-tools ->
>>>> /org/apache/directory/server/ldap/handlers/extended/tools
>>>> -> server-tools project was out of the build. left untouched
>>>>
>>>> --------------------------------------------------------------------------------------------------------------------------------------
>>>>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
>>>> /org/apache/directory/shared/ldap/codec/osgi
>>>> ./shared/ldap/codec/standalone ->
>>>> /org/apache/directory/shared/ldap/codec/osgi/standalone
>>>> -> was test package, changed as suggested
>>>> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec
>>>> -> /org/apache/directory/shared/ldap/codec/osgi/extras
>>>> -> was test package, changed as suggested
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------------------
>>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>>> ./shared/ldap/extras/codec
>>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>>> ./shared/ldap/extras/codec-api ->
>>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
>>>> -> changed as suggested
>>>>
>>>>  Regards,
>>>> Gokturk
>>>>
>>>
>>>
>>
> Regards,
> Gokturk
>

Re: [ADS 2.0] OSGi : solving package conflicts

[Göktürk Gezer <go...@gmail.com>]

On Sun, Oct 9, 2011 at 11:55 PM, Stefan Seelmann <se...@apache.org>wrote:

>
>
> On Sun, Oct 9, 2011 at 9:02 PM, Stefan Seelmann <se...@apache.org>wrote:
>
>> On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com>wrote:
>>
>>> Hi,
>>> I attached a patch that solves these package conflicts. But i'm still
>>> unsure about working on trunk.Package renamings are something hard to
>>> describe as diff. Right now, this diff zeroes the old package contents, add
>>> new ones and modify other parts of code to use new packages. i can also
>>> create a script to make your local copy consistent after patch, and then you
>>> can commit like that. So, guide me to the correct way of doing it.
>>>
>>> Here is a change list:
>>>
>>> /org/apache/directory/server ./apacheds/http-directory-bridge
>>> -> changed to /org/apache/directory/server/bridge/http
>>>
>>
>> done
>>
>>
>>> /org/apache/directory/server ./apacheds/service
>>>
>>> /org/apache/directory/server ./apacheds/wrapper ->
>>> /org/apache/directory/server/wrapper
>>> -> changed as suggested
>>>
>>
>> done
>> also changed reference to ApacheDsTanukiWrapper in
>> installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/wrapper-installation.conf
>>
>>
>>>
>>> /org/apache/directory/server/config ./apacheds/server-config
>>> /org/apache/directory/server/config ./apacheds/service-builder ->
>>> /org/apache/directory/server/config/builder
>>>
>>
>> done
>>
>> I committed the previous changes. The next changes are a bit more tricky
>> as those guys are also used in Studio.
>>
>>
>>> /org/apache/directory/server/core ./apacheds/core
>>> /org/apache/directory/server/core ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api
>>>
>>
> done
> Made CacheService constructor public. Should this class be moved to
> apacheds-core?
>
i found no beneficial usage for it on apacheds-core-api.

>
>
>>  /org/apache/directory/server/core/changelog ./apacheds/core
>>> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/changelog
>>>
>>
> done
>
> /org/apache/directory/server/core/event ./apacheds/core
>>> /org/apache/directory/server/core/event ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/event
>>>
>>
> done
> Made RegistrationEntry constructor and method public.
>
I was cautios about contructor visibilities, but they're necessary. I hope
they're not meant to be privite.

>
>
>> /org/apache/directory/server/core/interceptor ./apacheds/core
>>> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/interceptor
>>>
>>
> done, including interceptor.context package
>
>
>> /org/apache/directory/server/core/journal ./apacheds/core
>>>
>>  /org/apache/directory/server/core/journal ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/journal
>>>
>>
> done
>
>  /org/apache/directory/server/core/partition ./apacheds/core
>>> /org/apache/directory/server/core/partition ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/partition
>>>
>> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
>>> /org/apache/directory/server/core/partition/impl
>>> -> was test package, changed to
>>> /org/apache/directory/server/core/partition/ldif
>>>
>>
> done, good catch with the test package
>
> /org/apache/directory/server/core/replication ./apacheds/core
>>> /org/apache/directory/server/core/replication ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/replication
>>>
>>
> Can't find this package, has this been moved before?
>
Yes i guess, i couldn't find it too.

>
>  /org/apache/directory/server/core/schema ./apacheds/core
>>> /org/apache/directory/server/core/schema ./apacheds/core-api ->
>>> /org/apache/directory/server/core/api/schema
>>>
>>
> done, but the classes in that package should be reviews and eventually
> moved to apacheds-core
>
> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
>>> /org/apache/directory/server/core/schema/jdbm
>>>
>>
> Moved PartitionSchemaLoaderTest from jdbm-partition to core-integ as
> described in a TODO within that class, removed the package.
>
>
> -> All packages(source and test) under apacheds-api is moved into
>>> org/apache/directory/server/core/api package
>>>
>>
> Do you mean you renamed all packages even those that are not conflicting? I
> didn't renamed those in the first step but I agree that it makes sense to do
> so. However before that we should review if those packages belong to the
> "api" module. The remaining packages are
> - org.apache.directory.server.core.administrative
> - org.apache.directory.server.core.entry
> - org.apache.directory.server.core.filtering
> - org.apache.directory.server.core.invocation
> - org.apache.directory.server.core.schema.registries.synchronizers
>

Yes i renamed all even if they're not conflicting. It seems neater to me.

>
>
>>  -> DefaultPartitionNexus class is moved from apacheds-core to
>>> apacheds-core-api to defeat cyclic builds
>>>
>>
> That was not required, there were just unused imports that I deleted.
>
Yeah, that's better. I didn't look closely at how it's used in core-api.

>
>
> When I run the test I saw that LdapConnectionFactory (in
> shared-ldap-client-api) has a method getCoreSessionConnection() the creates
> an instance of LdapCoreSessionConnection via reflection. IMO this should be
> moved to some ApacheDS module.
>
I handled that by just renaming that package name to its new name. This
class is being heavily used by ApacheDS modules for testing, having it in
some ApacheDS module means more.

>
> Committed so far.
>

Thanks.


>
>
>>> --------------------------------------------------------------------------------------------------------------------------
>>> This is not a conflict (test) :
>>> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
>>> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------
>>> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
>>> -> /org/apache/directory/server/kerberos/protocol/codec
>>> -> changed as suggested
>>> /org/apache/directory/server/kerberos/protocol
>>> ./apacheds/protocol-kerberos
>>>
>>> ------------------------------------------------------------------------------------------------------------------------------
>>>  /org/apache/directory/server/ldap/handlers/extended
>>> ./apacheds/protocol-ldap
>>> /org/apache/directory/server/ldap/handlers/extended
>>> ./apacheds/server-tools ->
>>> /org/apache/directory/server/ldap/handlers/extended/tools
>>> -> server-tools project was out of the build. left untouched
>>>
>>> --------------------------------------------------------------------------------------------------------------------------------------
>>>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
>>> /org/apache/directory/shared/ldap/codec/osgi
>>> ./shared/ldap/codec/standalone ->
>>> /org/apache/directory/shared/ldap/codec/osgi/standalone
>>> -> was test package, changed as suggested
>>> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec
>>> -> /org/apache/directory/shared/ldap/codec/osgi/extras
>>> -> was test package, changed as suggested
>>>
>>> -----------------------------------------------------------------------------------------------------------------------------------
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>> ./shared/ldap/extras/codec
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>>> ./shared/ldap/extras/codec-api ->
>>> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
>>> -> changed as suggested
>>>
>>>  Regards,
>>> Gokturk
>>>
>>
>>
>
Regards,
Gokturk

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

On Sun, Oct 9, 2011 at 9:02 PM, Stefan Seelmann <se...@apache.org> wrote:

> On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com>wrote:
>
>> Hi,
>> I attached a patch that solves these package conflicts. But i'm still
>> unsure about working on trunk.Package renamings are something hard to
>> describe as diff. Right now, this diff zeroes the old package contents, add
>> new ones and modify other parts of code to use new packages. i can also
>> create a script to make your local copy consistent after patch, and then you
>> can commit like that. So, guide me to the correct way of doing it.
>>
>> Here is a change list:
>>
>> /org/apache/directory/server ./apacheds/http-directory-bridge
>> -> changed to /org/apache/directory/server/bridge/http
>>
>
> done
>
>
>> /org/apache/directory/server ./apacheds/service
>>
>> /org/apache/directory/server ./apacheds/wrapper ->
>> /org/apache/directory/server/wrapper
>> -> changed as suggested
>>
>
> done
> also changed reference to ApacheDsTanukiWrapper in
> installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/wrapper-installation.conf
>
>
>>
>> /org/apache/directory/server/config ./apacheds/server-config
>> /org/apache/directory/server/config ./apacheds/service-builder ->
>> /org/apache/directory/server/config/builder
>>
>
> done
>
> I committed the previous changes. The next changes are a bit more tricky as
> those guys are also used in Studio.
>
>
>> /org/apache/directory/server/core ./apacheds/core
>> /org/apache/directory/server/core ./apacheds/core-api ->
>> /org/apache/directory/server/core/api
>>
>
done
Made CacheService constructor public. Should this class be moved to
apacheds-core?


>  /org/apache/directory/server/core/changelog ./apacheds/core
>> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/changelog
>>
>
done

/org/apache/directory/server/core/event ./apacheds/core
>> /org/apache/directory/server/core/event ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/event
>>
>
done
Made RegistrationEntry constructor and method public.


> /org/apache/directory/server/core/interceptor ./apacheds/core
>> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/interceptor
>>
>
done, including interceptor.context package


> /org/apache/directory/server/core/journal ./apacheds/core
>>
>  /org/apache/directory/server/core/journal ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/journal
>>
>
done

 /org/apache/directory/server/core/partition ./apacheds/core
>> /org/apache/directory/server/core/partition ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/partition
>>
> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
>> /org/apache/directory/server/core/partition/impl
>> -> was test package, changed to
>> /org/apache/directory/server/core/partition/ldif
>>
>
done, good catch with the test package

/org/apache/directory/server/core/replication ./apacheds/core
>> /org/apache/directory/server/core/replication ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/replication
>>
>
Can't find this package, has this been moved before?

 /org/apache/directory/server/core/schema ./apacheds/core
>> /org/apache/directory/server/core/schema ./apacheds/core-api ->
>> /org/apache/directory/server/core/api/schema
>>
>
done, but the classes in that package should be reviews and eventually moved
to apacheds-core

/org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
>> /org/apache/directory/server/core/schema/jdbm
>>
>
Moved PartitionSchemaLoaderTest from jdbm-partition to core-integ as
described in a TODO within that class, removed the package.

-> All packages(source and test) under apacheds-api is moved into
>> org/apache/directory/server/core/api package
>>
>
Do you mean you renamed all packages even those that are not conflicting? I
didn't renamed those in the first step but I agree that it makes sense to do
so. However before that we should review if those packages belong to the
"api" module. The remaining packages are
- org.apache.directory.server.core.administrative
- org.apache.directory.server.core.entry
- org.apache.directory.server.core.filtering
- org.apache.directory.server.core.invocation
- org.apache.directory.server.core.schema.registries.synchronizers


>  -> DefaultPartitionNexus class is moved from apacheds-core to
>> apacheds-core-api to defeat cyclic builds
>>
>
That was not required, there were just unused imports that I deleted.


When I run the test I saw that LdapConnectionFactory (in
shared-ldap-client-api) has a method getCoreSessionConnection() the creates
an instance of LdapCoreSessionConnection via reflection. IMO this should be
moved to some ApacheDS module.

Committed so far.


>> --------------------------------------------------------------------------------------------------------------------------
>> This is not a conflict (test) :
>> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
>> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
>>
>> ---------------------------------------------------------------------------------------------------------------------------
>> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
>> -> /org/apache/directory/server/kerberos/protocol/codec
>> -> changed as suggested
>> /org/apache/directory/server/kerberos/protocol
>> ./apacheds/protocol-kerberos
>>
>> ------------------------------------------------------------------------------------------------------------------------------
>>  /org/apache/directory/server/ldap/handlers/extended
>> ./apacheds/protocol-ldap
>> /org/apache/directory/server/ldap/handlers/extended
>> ./apacheds/server-tools ->
>> /org/apache/directory/server/ldap/handlers/extended/tools
>> -> server-tools project was out of the build. left untouched
>>
>> --------------------------------------------------------------------------------------------------------------------------------------
>>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
>> /org/apache/directory/shared/ldap/codec/osgi
>> ./shared/ldap/codec/standalone ->
>> /org/apache/directory/shared/ldap/codec/osgi/standalone
>> -> was test package, changed as suggested
>> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec ->
>> /org/apache/directory/shared/ldap/codec/osgi/extras
>> -> was test package, changed as suggested
>>
>> -----------------------------------------------------------------------------------------------------------------------------------
>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>> ./shared/ldap/extras/codec
>> /org/apache/directory/shared/ldap/extras/controls/ppolicy
>> ./shared/ldap/extras/codec-api ->
>> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
>> -> changed as suggested
>>
>>  Regards,
>> Gokturk
>>
>
>

Re: [ADS 2.0] OSGi : solving package conflicts

[Stefan Seelmann <se...@apache.org>]

On Sat, Oct 8, 2011 at 5:12 PM, Göktürk Gezer <go...@gmail.com>wrote:

> Hi,
> I attached a patch that solves these package conflicts. But i'm still
> unsure about working on trunk.Package renamings are something hard to
> describe as diff. Right now, this diff zeroes the old package contents, add
> new ones and modify other parts of code to use new packages. i can also
> create a script to make your local copy consistent after patch, and then you
> can commit like that. So, guide me to the correct way of doing it.
>
> Here is a change list:
>
> /org/apache/directory/server ./apacheds/http-directory-bridge
> -> changed to /org/apache/directory/server/bridge/http
>

done


> /org/apache/directory/server ./apacheds/service
>
> /org/apache/directory/server ./apacheds/wrapper ->
> /org/apache/directory/server/wrapper
> -> changed as suggested
>

done
also changed reference to ApacheDsTanukiWrapper in
installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/wrapper-installation.conf


>
> /org/apache/directory/server/config ./apacheds/server-config
> /org/apache/directory/server/config ./apacheds/service-builder ->
> /org/apache/directory/server/config/builder
>

done

I committed the previous changes. The next changes are a bit more tricky as
those guys are also used in Studio.


> /org/apache/directory/server/core ./apacheds/core
> /org/apache/directory/server/core ./apacheds/core-api ->
> /org/apache/directory/server/core/api
>
> /org/apache/directory/server/core/changelog ./apacheds/core
> /org/apache/directory/server/core/changelog ./apacheds/core-api ->
> /org/apache/directory/server/core/api/changelog
>
> /org/apache/directory/server/core/event ./apacheds/core
> /org/apache/directory/server/core/event ./apacheds/core-api ->
> /org/apache/directory/server/core/api/event
>
> /org/apache/directory/server/core/interceptor ./apacheds/core
> /org/apache/directory/server/core/interceptor ./apacheds/core-api ->
> /org/apache/directory/server/core/api/interceptor
>
> /org/apache/directory/server/core/journal ./apacheds/core
> /org/apache/directory/server/core/journal ./apacheds/core-api ->
> /org/apache/directory/server/core/api/journal
>
> /org/apache/directory/server/core/partition ./apacheds/core
> /org/apache/directory/server/core/partition ./apacheds/core-api ->
> /org/apache/directory/server/core/api/partition
> /org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
> /org/apache/directory/server/core/partition/impl
> -> was test package, changed to
> /org/apache/directory/server/core/partition/ldif
>
> /org/apache/directory/server/core/replication ./apacheds/core
> /org/apache/directory/server/core/replication ./apacheds/core-api ->
> /org/apache/directory/server/core/api/replication
>
> /org/apache/directory/server/core/schema ./apacheds/core
> /org/apache/directory/server/core/schema ./apacheds/core-api ->
> /org/apache/directory/server/core/api/schema
> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
> /org/apache/directory/server/core/schema/jdbm
> -> was test package, changed as suggested.
>
>
> -> All packages(source and test) under apacheds-api is moved into
> org/apache/directory/server/core/api package
> -> DefaultPartitionNexus class is moved from apacheds-core to
> apacheds-core-api to defeat cyclic builds
>
>
> --------------------------------------------------------------------------------------------------------------------------
> This is not a conflict (test) :
> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
>
> ---------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec ->
> /org/apache/directory/server/kerberos/protocol/codec
> -> changed as suggested
> /org/apache/directory/server/kerberos/protocol ./apacheds/protocol-kerberos
>
> ------------------------------------------------------------------------------------------------------------------------------
>  /org/apache/directory/server/ldap/handlers/extended
> ./apacheds/protocol-ldap
> /org/apache/directory/server/ldap/handlers/extended ./apacheds/server-tools
> -> /org/apache/directory/server/ldap/handlers/extended/tools
> -> server-tools project was out of the build. left untouched
>
> --------------------------------------------------------------------------------------------------------------------------------------
>  /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/standalone
> -> /org/apache/directory/shared/ldap/codec/osgi/standalone
> -> was test package, changed as suggested
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec ->
> /org/apache/directory/shared/ldap/codec/osgi/extras
> -> was test package, changed as suggested
>
> -----------------------------------------------------------------------------------------------------------------------------------
> /org/apache/directory/shared/ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec
> /org/apache/directory/shared/ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec-api ->
> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api
> -> changed as suggested
>
>  Regards,
> Gokturk
>

Re: [ADS 2.0] OSGi : solving package conflicts

[Göktürk Gezer <go...@gmail.com>]

Hi,
I attached a patch that solves these package conflicts. But i'm still unsure
about working on trunk.Package renamings are something hard to describe as
diff. Right now, this diff zeroes the old package contents, add new ones and
modify other parts of code to use new packages. i can also create a script
to make your local copy consistent after patch, and then you can commit like
that. So, guide me to the correct way of doing it.

Here is a change list:

/org/apache/directory/server ./apacheds/http-directory-bridge
-> changed to /org/apache/directory/server/bridge/http

/org/apache/directory/server ./apacheds/service

/org/apache/directory/server ./apacheds/wrapper ->
/org/apache/directory/server/wrapper
-> changed as suggested

------------------------------------------------------------------------------------------------------------------------

/org/apache/directory/server/config ./apacheds/server-config
/org/apache/directory/server/config ./apacheds/service-builder ->
/org/apache/directory/server/config/builder

/org/apache/directory/server/core ./apacheds/core
/org/apache/directory/server/core ./apacheds/core-api ->
/org/apache/directory/server/core/api

/org/apache/directory/server/core/changelog ./apacheds/core
/org/apache/directory/server/core/changelog ./apacheds/core-api ->
/org/apache/directory/server/core/api/changelog

/org/apache/directory/server/core/event ./apacheds/core
/org/apache/directory/server/core/event ./apacheds/core-api ->
/org/apache/directory/server/core/api/event

/org/apache/directory/server/core/interceptor ./apacheds/core
/org/apache/directory/server/core/interceptor ./apacheds/core-api ->
/org/apache/directory/server/core/api/interceptor

/org/apache/directory/server/core/journal ./apacheds/core
/org/apache/directory/server/core/journal ./apacheds/core-api ->
/org/apache/directory/server/core/api/journal

/org/apache/directory/server/core/partition ./apacheds/core
/org/apache/directory/server/core/partition ./apacheds/core-api ->
/org/apache/directory/server/core/api/partition
/org/apache/directory/server/core/partition ./apacheds/ldif-partition ->
/org/apache/directory/server/core/partition/impl
-> was test package, changed to
/org/apache/directory/server/core/partition/ldif

/org/apache/directory/server/core/replication ./apacheds/core
/org/apache/directory/server/core/replication ./apacheds/core-api ->
/org/apache/directory/server/core/api/replication

/org/apache/directory/server/core/schema ./apacheds/core
/org/apache/directory/server/core/schema ./apacheds/core-api ->
/org/apache/directory/server/core/api/schema
/org/apache/directory/server/core/schema ./apacheds/jdbm-partition ->
/org/apache/directory/server/core/schema/jdbm
-> was test package, changed as suggested.


-> All packages(source and test) under apacheds-api is moved into
org/apache/directory/server/core/api package
-> DefaultPartitionNexus class is moved from apacheds-core to
apacheds-core-api to defeat cyclic builds

--------------------------------------------------------------------------------------------------------------------------
This is not a conflict (test) :
/org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
/org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
---------------------------------------------------------------------------------------------------------------------------
/org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec ->
/org/apache/directory/server/kerberos/protocol/codec
-> changed as suggested
/org/apache/directory/server/kerberos/protocol ./apacheds/protocol-kerberos
------------------------------------------------------------------------------------------------------------------------------
/org/apache/directory/server/ldap/handlers/extended ./apacheds/protocol-ldap
/org/apache/directory/server/ldap/handlers/extended ./apacheds/server-tools
-> /org/apache/directory/server/ldap/handlers/extended/tools
-> server-tools project was out of the build. left untouched
--------------------------------------------------------------------------------------------------------------------------------------
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/standalone
-> /org/apache/directory/shared/ldap/codec/osgi/standalone
-> was test package, changed as suggested
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec ->
/org/apache/directory/shared/ldap/codec/osgi/extras
-> was test package, changed as suggested
-----------------------------------------------------------------------------------------------------------------------------------
/org/apache/directory/shared/ldap/extras/controls/ppolicy
./shared/ldap/extras/codec
/org/apache/directory/shared/ldap/extras/controls/ppolicy
./shared/ldap/extras/codec-api ->
/org/apache/directory/shared/ldap/extras/controls/ppolicy/api
-> changed as suggested

Regards,
Gokturk

Re: [ADS 2.0] OSGi : solving package conflicts

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

the following packages are conflicting. I suggest the following 
moifications to fix those conflicts :
/org/apache/directory/server ./apacheds/http-directory-bridge
> /org/apache/directory/server ./apacheds/service
> /org/apache/directory/server ./apacheds/wrapper -> 
> /org/apache/directory/server/wrapper
> /org/apache/directory/server/config ./apacheds/server-config
> /org/apache/directory/server/config ./apacheds/service-builder -> 
> /org/apache/directory/server/config/builder
> /org/apache/directory/server/core ./apacheds/core
> /org/apache/directory/server/core ./apacheds/core-api -> 
> /org/apache/directory/server/core/api
> /org/apache/directory/server/core/changelog ./apacheds/core
> /org/apache/directory/server/core/changelog ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/changelog
> /org/apache/directory/server/core/event ./apacheds/core
> /org/apache/directory/server/core/event ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/event
> /org/apache/directory/server/core/interceptor ./apacheds/core
> /org/apache/directory/server/core/interceptor ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/interceptor
> /org/apache/directory/server/core/journal ./apacheds/core
> /org/apache/directory/server/core/journal ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/journal
> /org/apache/directory/server/core/partition ./apacheds/core
> /org/apache/directory/server/core/partition ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/partition
> /org/apache/directory/server/core/partition ./apacheds/ldif-partition 
> -> /org/apache/directory/server/core/partition/impl
> /org/apache/directory/server/core/replication ./apacheds/core
> /org/apache/directory/server/core/replication ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/replication
> /org/apache/directory/server/core/schema ./apacheds/core
> /org/apache/directory/server/core/schema ./apacheds/core-api -> 
> /org/apache/directory/server/core/api/schema
> /org/apache/directory/server/core/schema ./apacheds/jdbm-partition -> 
> /org/apache/directory/server/core/schema/jdbm

This is not a conflict (test) :
> /org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
> /org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos

> /org/apache/directory/server/kerberos/protocol 
> ./apacheds/kerberos-codec -> 
> /org/apache/directory/server/kerberos/protocol/codec
> /org/apache/directory/server/kerberos/protocol 
> ./apacheds/protocol-kerberos
> /org/apache/directory/server/ldap/handlers/extended 
> ./apacheds/protocol-ldap
> /org/apache/directory/server/ldap/handlers/extended 
> ./apacheds/server-tools -> 
> /org/apache/directory/server/ldap/handlers/extended/tools
> /org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
> /org/apache/directory/shared/ldap/codec/osgi 
> ./shared/ldap/codec/standalone -> 
> /org/apache/directory/shared/ldap/codec/osgi/standalone
> /org/apache/directory/shared/ldap/codec/osgi 
> ./shared/ldap/extras/codec -> 
> /org/apache/directory/shared/ldap/codec/osgi/extras
> /org/apache/directory/shared/ldap/extras/controls/ppolicy 
> ./shared/ldap/extras/codec
> /org/apache/directory/shared/ldap/extras/controls/ppolicy 
> ./shared/ldap/extras/codec-api -> 
> /org/apache/directory/shared/ldap/extras/controls/ppolicy/api

Thoughts ?


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

Re: [ADS 2.0] OSGi

[Emmanuel Lécharny <el...@apache.org>]

On 10/6/11 8:26 PM, Göktürk Gezer wrote:
> <snip/>
>>
>>> Actual substeps needed for implementing service layer will come out
>>> clearly
>>> after we decided what aspects needs to be extendable.
>>>
>> Pretty much what I listed above, by I may have missed some aspects.
>>
>> I suggest we start with the first step in any case, before thinking about
>> implementing services, as we will face some serious questions when we will
>> start with services (about service initialization, dependencies, etc...).
>>
> Yes, there is no reason for us to wait on service decisions. The first part
> is mandatory anyway. But lets keep the service topic alive, because all it
> needs is more discussion before we can start implementing it.

Sure
>
>
>> Feel free to comment !
>
> I guess we need a jira issue for me to attach patches.

JIRA created : https://issues.apache.org/jira/browse/DIRSERVER-1667

> Are we going to
> create a branch, or work on the trunk?
I think it's better to work on trunk. The idea is to release fast, even 
if we don't have many fixes. In 2.0.0-M3, we should have OSGi and MVCC 
implemented.


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

Re: [ADS 2.0] OSGi

[Göktürk Gezer <go...@gmail.com>]

On Thu, Oct 6, 2011 at 8:10 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> On 10/6/11 12:29 PM, Göktürk Gezer wrote:
>
>> Hi Emmanuel,
>>
>> I would like to elaborate the things about OSGI those we've talked with
>> you
>> and Alex here. So that we can have some road map.
>>
>> With respect to OSGI's 3 layer (modularity, lifecycle and services), we
>> can
>> divide our future efforts into 3 main step. Actually the first and second
>> steps can be merged in one.
>>
>> *Step1 (Implementing Modularity and Lifecycle)*
>>
>>
>> This step will contain mostly configuration changes on POM files.
>>
>> * As you've told, conflict packages problem must be solved or at least
>> down
>> to a minimum degree. For the situations those are impossible to completely
>> solve that issue, we may look into the "fragments" feature that is
>> designed
>> for practically one bundle backing the other with extra content. However
>> this is not an elegant solution. We must ensure the separation as much as
>> we
>> can.
>>
> I don't think we will have big issues removing the conflicting packages.
> Here is the list of packages present in more than one module :
> /org/apache/directory/server ./apacheds/http-directory-**bridge
> /org/apache/directory/server ./apacheds/service
> /org/apache/directory/server ./apacheds/wrapper
> /org/apache/directory/server/**config ./apacheds/server-config
> /org/apache/directory/server/**config ./apacheds/service-builder
> /org/apache/directory/server/**core ./apacheds/core
> /org/apache/directory/server/**core ./apacheds/core-api
> /org/apache/directory/server/**core/changelog ./apacheds/core
> /org/apache/directory/server/**core/changelog ./apacheds/core-api
> /org/apache/directory/server/**core/event ./apacheds/core
> /org/apache/directory/server/**core/event ./apacheds/core-api
> /org/apache/directory/server/**core/interceptor ./apacheds/core
> /org/apache/directory/server/**core/interceptor ./apacheds/core-api
> /org/apache/directory/server/**core/journal ./apacheds/core
> /org/apache/directory/server/**core/journal ./apacheds/core-api
> /org/apache/directory/server/**core/partition ./apacheds/core
> /org/apache/directory/server/**core/partition ./apacheds/core-api
> /org/apache/directory/server/**core/partition ./apacheds/ldif-partition
> /org/apache/directory/server/**core/replication ./apacheds/core
> /org/apache/directory/server/**core/replication ./apacheds/core-api
> /org/apache/directory/server/**core/schema ./apacheds/core
> /org/apache/directory/server/**core/schema ./apacheds/core-api
> /org/apache/directory/server/**core/schema ./apacheds/jdbm-partition
> /org/apache/directory/server/**kerberos/kdc ./apacheds/kerberos-test
> /org/apache/directory/server/**kerberos/kdc ./apacheds/protocol-kerberos
> /org/apache/directory/server/**kerberos/protocol ./apacheds/kerberos-codec
> /org/apache/directory/server/**kerberos/protocol
> ./apacheds/protocol-kerberos
> /org/apache/directory/server/**ldap/handlers/extended
> ./apacheds/protocol-ldap
> /org/apache/directory/server/**ldap/handlers/extended
> ./apacheds/server-tools
> /org/apache/directory/shared/**ldap/codec/osgi ./shared/ldap/codec/core
> /org/apache/directory/shared/**ldap/codec/osgi
> ./shared/ldap/codec/standalone
> /org/apache/directory/shared/**ldap/codec/osgi ./shared/ldap/extras/codec
> /org/apache/directory/shared/**ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec
> /org/apache/directory/shared/**ldap/extras/controls/ppolicy
> ./shared/ldap/extras/codec-api


Yes it seems fine. Having no conflict packages on APIs is a good news. I'll
look into these packages.


>




> We can first start by cleaning those conflicts.
>
>  * After dividing the modules's packages properly, we're gonna introduce
>> OSGI
>> specific instructions into each modules POM, making them an OSGI bundle.
>> And
>> at that point we must introduce ApacheDS's 3th party dependencies as
>> bundle
>> imports into corresponding modules.
>>
> Yeah. Modifying the poms is easy, adding 3rd parties poms is already done
> for Studio, we can probably inherit from what has been done


>
>  * Modify the existing apacheds-service module (or add a new one) for
>> embedding the felix, deploying the core and dependency bundles into it,
>> and
>> then starting the ApacheDS on top of Felix.
>>
> +1. Not too complicated either.
>
>
>  * Create a Karaf feature description xml file for deploying ApacheDS into
>> Karaf easilly with all of its dependencies.
>>
>
> Can you tell us a bit more about Karaf ?


Karaf is an OSGI container. It provides good management for OSGI framework
of our choice. Easy deployment and configuration of bundles, remote
management, and  pretty good shell is some of karaf's cool features. Feature
file i mentioned is used to deploy complete application with all of its
bundles and dependencies into Karaf. This file simply lists the bundles
required for ApacheDS to work. End-users can just download that xml file and
then deploy ApacheDS into the Karaf using it.


>
>> This first step is going to be mostly a configuration job. If we are
>> lucky,
>> there won't be much code changes at that step. Considering the fact that
>> ApacheDS's code is designed to be embeddable, we are lucky. It already
>> works
>> as megabundle on all frameworks without modification.
>>
>
> IMO? this would be a one to two weeks work, max.
>

Yeah, i think the same.


>> *Step2 (Implementing Services)*
>> *
>>
>> *
>> Using services layer in ApacheDS will give you the runtime extendibility
>> you
>> want. But interacting with service layer may not be the wise choice. To
>> deal
>> with the wildly dynamic nature of the OSGI, we must use some component
>> model
>> on top of services. Considering two mainly used component frameworks,
>> blueprint and IPojo, it seems IPojo is the correct choice. To list my
>> reasons of this choice:
>>
>> * IPojo lets you describe the component model with annotations. It also
>> accepts xml and also gives you the API to create your own way other than
>> these two.
>> * Its highly extendable, letting you implement your custom needs without
>> need to change the core IPojo code.
>> * Field injection feature of it is the perfect way for making existing
>> code
>> to use services with minimum modification.
>>
>> List goes long...
>>
>> Listing the things we must do for implementing service layer depends on
>> what
>> we want to do with it. For example we can provide partition
>> implementations
>> as services, so changing the code to see those arriving implementations in
>> the form of implementing bundles and start to use them immediately.
>>
>
> We first have to list all the services we want. I assume we could have
> around 10 to 20 (max) services.
>
> Some might be loaded only at startup, and never changed (or rarely), and
> others might be loaded at will, depending on what the user may do (for
> instance, I'm thinking about store procedures).
>
> from the top of my head, here are some of the needed services :
> - partitions
> - authenticators
> - password policies
> - schema elements (we have 7 different kind of them)
> - interceptors
> - loggers
> - each of the protocol we implemented (NTP, Kerberos, LDAP, etc)
> - network layer (currently, we only use MINA)
> - replication
> - extended operations
>
> (I may have missed some of them)


List is longer than i expected.


>
>
>> The ability to configure the arriving component's(service's) configuration
>> data inside ApacheDS DIT will be an ease for us, the 3th party component
>> writers and the users. I implemented that feature as test research. It has
>> some issues but not unsolvable, we just have to set the slider between
>> speed
>> and code clarity.
>>
> Now that all teh configuration is in DiT, this could be easier.


Exactly !


>
>
>> Actual substeps needed for implementing service layer will come out
>> clearly
>> after we decided what aspects needs to be extendable.
>>
> Pretty much what I listed above, by I may have missed some aspects.
>
> I suggest we start with the first step in any case, before thinking about
> implementing services, as we will face some serious questions when we will
> start with services (about service initialization, dependencies, etc...).
>

Yes, there is no reason for us to wait on service decisions. The first part
is mandatory anyway. But lets keep the service topic alive, because all it
needs is more discussion before we can start implementing it.


> Feel free to comment !


I guess we need a jira issue for me to attach patches. Are we going to
create a branch, or work on the trunk?


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

Re: [ADS 2.0] OSGi

[Emmanuel Lécharny <el...@apache.org>]

On 10/6/11 12:29 PM, Göktürk Gezer wrote:
> Hi Emmanuel,
>
> I would like to elaborate the things about OSGI those we've talked with you
> and Alex here. So that we can have some road map.
>
> With respect to OSGI's 3 layer (modularity, lifecycle and services), we can
> divide our future efforts into 3 main step. Actually the first and second
> steps can be merged in one.
>
> *Step1 (Implementing Modularity and Lifecycle)*
>
> This step will contain mostly configuration changes on POM files.
>
> * As you've told, conflict packages problem must be solved or at least down
> to a minimum degree. For the situations those are impossible to completely
> solve that issue, we may look into the "fragments" feature that is designed
> for practically one bundle backing the other with extra content. However
> this is not an elegant solution. We must ensure the separation as much as we
> can.
I don't think we will have big issues removing the conflicting packages. 
Here is the list of packages present in more than one module :
/org/apache/directory/server ./apacheds/http-directory-bridge
/org/apache/directory/server ./apacheds/service
/org/apache/directory/server ./apacheds/wrapper
/org/apache/directory/server/config ./apacheds/server-config
/org/apache/directory/server/config ./apacheds/service-builder
/org/apache/directory/server/core ./apacheds/core
/org/apache/directory/server/core ./apacheds/core-api
/org/apache/directory/server/core/changelog ./apacheds/core
/org/apache/directory/server/core/changelog ./apacheds/core-api
/org/apache/directory/server/core/event ./apacheds/core
/org/apache/directory/server/core/event ./apacheds/core-api
/org/apache/directory/server/core/interceptor ./apacheds/core
/org/apache/directory/server/core/interceptor ./apacheds/core-api
/org/apache/directory/server/core/journal ./apacheds/core
/org/apache/directory/server/core/journal ./apacheds/core-api
/org/apache/directory/server/core/partition ./apacheds/core
/org/apache/directory/server/core/partition ./apacheds/core-api
/org/apache/directory/server/core/partition ./apacheds/ldif-partition
/org/apache/directory/server/core/replication ./apacheds/core
/org/apache/directory/server/core/replication ./apacheds/core-api
/org/apache/directory/server/core/schema ./apacheds/core
/org/apache/directory/server/core/schema ./apacheds/core-api
/org/apache/directory/server/core/schema ./apacheds/jdbm-partition
/org/apache/directory/server/kerberos/kdc ./apacheds/kerberos-test
/org/apache/directory/server/kerberos/kdc ./apacheds/protocol-kerberos
/org/apache/directory/server/kerberos/protocol ./apacheds/kerberos-codec
/org/apache/directory/server/kerberos/protocol ./apacheds/protocol-kerberos
/org/apache/directory/server/ldap/handlers/extended 
./apacheds/protocol-ldap
/org/apache/directory/server/ldap/handlers/extended ./apacheds/server-tools
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/core
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/codec/standalone
/org/apache/directory/shared/ldap/codec/osgi ./shared/ldap/extras/codec
/org/apache/directory/shared/ldap/extras/controls/ppolicy 
./shared/ldap/extras/codec
/org/apache/directory/shared/ldap/extras/controls/ppolicy 
./shared/ldap/extras/codec-api

We can first start by cleaning those conflicts.
> * After dividing the modules's packages properly, we're gonna introduce OSGI
> specific instructions into each modules POM, making them an OSGI bundle. And
> at that point we must introduce ApacheDS's 3th party dependencies as bundle
> imports into corresponding modules.
Yeah. Modifying the poms is easy, adding 3rd parties poms is already 
done for Studio, we can probably inherit from what has been done.

> * Modify the existing apacheds-service module (or add a new one) for
> embedding the felix, deploying the core and dependency bundles into it, and
> then starting the ApacheDS on top of Felix.
+1. Not too complicated either.

> * Create a Karaf feature description xml file for deploying ApacheDS into
> Karaf easilly with all of its dependencies.

Can you tell us a bit more about Karaf ?
>
> This first step is going to be mostly a configuration job. If we are lucky,
> there won't be much code changes at that step. Considering the fact that
> ApacheDS's code is designed to be embeddable, we are lucky. It already works
> as megabundle on all frameworks without modification.

IMO? this would be a one to two weeks work, max.
>
> *Step2 (Implementing Services)*
> *
> *
> Using services layer in ApacheDS will give you the runtime extendibility you
> want. But interacting with service layer may not be the wise choice. To deal
> with the wildly dynamic nature of the OSGI, we must use some component model
> on top of services. Considering two mainly used component frameworks,
> blueprint and IPojo, it seems IPojo is the correct choice. To list my
> reasons of this choice:
>
> * IPojo lets you describe the component model with annotations. It also
> accepts xml and also gives you the API to create your own way other than
> these two.
> * Its highly extendable, letting you implement your custom needs without
> need to change the core IPojo code.
> * Field injection feature of it is the perfect way for making existing code
> to use services with minimum modification.
>
> List goes long...
>
> Listing the things we must do for implementing service layer depends on what
> we want to do with it. For example we can provide partition implementations
> as services, so changing the code to see those arriving implementations in
> the form of implementing bundles and start to use them immediately.

We first have to list all the services we want. I assume we could have 
around 10 to 20 (max) services.

Some might be loaded only at startup, and never changed (or rarely), and 
others might be loaded at will, depending on what the user may do (for 
instance, I'm thinking about store procedures).

from the top of my head, here are some of the needed services :
- partitions
- authenticators
- password policies
- schema elements (we have 7 different kind of them)
- interceptors
- loggers
- each of the protocol we implemented (NTP, Kerberos, LDAP, etc)
- network layer (currently, we only use MINA)
- replication
- extended operations

(I may have missed some of them)
>
> The ability to configure the arriving component's(service's) configuration
> data inside ApacheDS DIT will be an ease for us, the 3th party component
> writers and the users. I implemented that feature as test research. It has
> some issues but not unsolvable, we just have to set the slider between speed
> and code clarity.
Now that all teh configuration is in DiT, this could be easier.
>
> Actual substeps needed for implementing service layer will come out clearly
> after we decided what aspects needs to be extendable.
Pretty much what I listed above, by I may have missed some aspects.

I suggest we start with the first step in any case, before thinking 
about implementing services, as we will face some serious questions when 
we will start with services (about service initialization, dependencies, 
etc...).

Feel free to comment !


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

Re: [ADS 2.0] OSGi

[Göktürk Gezer <go...@gmail.com>]

Hi Emmanuel,

I would like to elaborate the things about OSGI those we've talked with you
and Alex here. So that we can have some road map.

With respect to OSGI's 3 layer (modularity, lifecycle and services), we can
divide our future efforts into 3 main step. Actually the first and second
steps can be merged in one.

*Step1 (Implementing Modularity and Lifecycle)*

This step will contain mostly configuration changes on POM files.

* As you've told, conflict packages problem must be solved or at least down
to a minimum degree. For the situations those are impossible to completely
solve that issue, we may look into the "fragments" feature that is designed
for practically one bundle backing the other with extra content. However
this is not an elegant solution. We must ensure the separation as much as we
can.
* After dividing the modules's packages properly, we're gonna introduce OSGI
specific instructions into each modules POM, making them an OSGI bundle. And
at that point we must introduce ApacheDS's 3th party dependencies as bundle
imports into corresponding modules.
* Modify the existing apacheds-service module (or add a new one) for
embedding the felix, deploying the core and dependency bundles into it, and
then starting the ApacheDS on top of Felix.
* Create a Karaf feature description xml file for deploying ApacheDS into
Karaf easilly with all of its dependencies.

This first step is going to be mostly a configuration job. If we are lucky,
there won't be much code changes at that step. Considering the fact that
ApacheDS's code is designed to be embeddable, we are lucky. It already works
as megabundle on all frameworks without modification.

*Step2 (Implementing Services)*
*
*
Using services layer in ApacheDS will give you the runtime extendibility you
want. But interacting with service layer may not be the wise choice. To deal
with the wildly dynamic nature of the OSGI, we must use some component model
on top of services. Considering two mainly used component frameworks,
blueprint and IPojo, it seems IPojo is the correct choice. To list my
reasons of this choice:

* IPojo lets you describe the component model with annotations. It also
accepts xml and also gives you the API to create your own way other than
these two.
* Its highly extendable, letting you implement your custom needs without
need to change the core IPojo code.
* Field injection feature of it is the perfect way for making existing code
to use services with minimum modification.

List goes long...

Listing the things we must do for implementing service layer depends on what
we want to do with it. For example we can provide partition implementations
as services, so changing the code to see those arriving implementations in
the form of implementing bundles and start to use them immediately.

The ability to configure the arriving component's(service's) configuration
data inside ApacheDS DIT will be an ease for us, the 3th party component
writers and the users. I implemented that feature as test research. It has
some issues but not unsolvable, we just have to set the slider between speed
and code clarity.

Actual substeps needed for implementing service layer will come out clearly
after we decided what aspects needs to be extendable.


Regards,
Gokturk