On Tue, May 10, 2011 at 3:57 PM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> Hi guys,
>
> following the bug opened by Daniel Fisher
> (https://issues.apache.org/jira/browse/DIRSHARED-125), I think we need to
> modify the way we use OSGi and Felix in shared.
>
> Right now, if the user has already an OSGi container running, we use it.
> Otherwise, we start Felix in StandaloneLdapCodecService (which, by the way,
> is not the right place to do that).
>
> What we should do is to ask for users not having an external OSGi container
> running and who want to extend the API to explicitely start Felix, instead
> of starting it ourselves.
>
> That leads to have three different working modes :
> 1) external OSGi container
> 2) no OSGi container at all
+1 to not start the container at all by default, cause in 99% cases
all we need is just opening a connection for performing either bind or
compare (think of a mail serrver authenticating users)
and frankly, I find it weird that the API used in a client starts a
container service by default!


Starting an embedded OSGi container has very little cost at all. It's not like starting up a J2EE container, and setting up all sorts of resources. Something tells me you're thinking this costs a lot in terms of time, processing and memory when its negligible on all aspects.
 
Secondly we have serious coupling issues in our code. If we're going to make controls and extended operations pluggable then we're going to need a modularity mechanism. OSGi is best for this.

However as you suggest we do not need these additional controls or extended operations most of the time. So perhaps we can lazy (on demand) start the container when we encounter a control or extended op we don't recognize as being standard or as one provided out of the box.

Regards,
Alex