directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: OSGi startup and shutdown problems
Date Wed, 11 May 2011 07:13:17 GMT
On 5/11/11 7:09 AM, Alex Karasulu wrote:
> On Tue, May 10, 2011 at 3:57 PM, Kiran Ayyagari<>wrote:
>> On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny<>
>> wrote:
>>> Hi guys,
>>> following the bug opened by Daniel Fisher
>>> (, 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.

This is not a time issue.

The problem is that we have no way to stop Felix but doing a 
felix.stop() when you use the API with a simple application. This is due 
to the fact that one Felix thread is not a deamon thread, and need to be 
explicitely shutdown.

There is an opened FELIX JIRA about it :

Emmanuel L├ęcharny

View raw message