On 5/11/11 7:09 AM, Alex Karasulu wrote:
On Tue, May 10, 2011 at 3:57 PM, Kiran Ayyagari<[email protected]>wrote:
On Tue, May 10, 2011 at 5:27 PM, Emmanuel Lecharny<[email protected]>
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.
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 :
https://issues.apache.org/jira/browse/FELIX-2434
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
