directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: OSGi startup and shutdown problems
Date Wed, 11 May 2011 08:47:53 GMT
Just my thoughts, as I had a discussion with Emmanuel yesterday on
this subject.  I must admit I don't know directory very much, so maybe
I'm off track.

Unless I misunderstood, the OSGi container is only used for
classloading and want to hide it.  However, if you try to hide the
OSGi stuff, the first time you'll have a resolution problem for a
bundle, you'll have a hard time explaining that to the user.

Let's take a simple example.  I see in your code at
https://github.com/apache/directory-shared/blob/trunk/ldap/codec/standalone/src/main/java/org/apache/directory/shared/ldap/codec/standalone/StandaloneLdapCodecService.java
that you export the slf4j pacakge in version 1.6.0 from the system
bundle.   What if a user start using a [1.6.1,2) range when importing
that package ? That will happen as soon as he's using the latest
version of slf4j in its maven dependencies (and people tend to upgrade
to latest version).    In that case, felix will start up correctly and
you won't see any problem, unless you're monitoring the bundles state
to check that everything has been resolved, etc...

I'm not saying OSGi is bad, I'm using it everyday and it's really
powerful.  But I've also learned that it's not a simple container to
manage.   I'm not sure hiding it will really work at the end.

Just my 2 cents.

On Wed, May 11, 2011 at 07:09, Alex Karasulu <akarasulu@apache.org> wrote:
> 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



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Mime
View raw message