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 <[email protected]> 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. > > 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/
