And btw, disabling the bundle cache by using reference:xxx urls in the activator should help to speed up the boot time and avoid most of the disk writes (though not all I guess).
On Wed, May 11, 2011 at 16:14, Guillaume Nodet <gno...@gmail.com> wrote: > On Wed, May 11, 2011 at 15:42, Alex Karasulu <akaras...@apache.org> wrote: >> Thanks Guillaume for your thoughts. Responding in this post to both of you >> in line ... >> >> On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny <elecha...@gmail.com> >> wrote: >>> >>> On 5/11/11 10:47 AM, Guillaume Nodet wrote: >>>> >>>> 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. >>>> >> >> No worries, we work with ApacheDS a lot and sometimes we're really off track >> :). >> >>>> >>>> Unless I misunderstood, the OSGi container is only used for >>>> classloading and want to hide it. >> >> I don't think we want to hide it. >> I guess to put it as simply as possible, we want to make it so users can >> extend the API to add new controls and extended requests. We need a >> modularity layer for this. >> >>>> >>>> However, if you try to hide the >>>> OSGi stuff, >> >> By "hide the OSGi stuff", do you mean embed the OSGi container in the >> application? > > Looking at the current api, an average user that does not use OSGi > won't see the fact that an embedded Felix is launched and it has no > access to it anyway, so that's what I mean by hidden. > >>>> >>>> the first time you'll have a resolution problem for a >>>> bundle, you'll have a hard time explaining that to the user. >>>> >> >> Yep. >> >>>> >>>> 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 >>> >>> This part of the code is really a bad hack, we are supposed to deduce the >>> versions to use from some configuration file. >> >> Yes this needs some TLC. It was more an experiment to see how embedding the >> container will manifest itself. We need some more precautionary code and >> better handling treating the system packages exported to a minimum. >> >>>> >>>> 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 ? >> >> Do you mean to say the user, writes and added a new bundle for an extension, >> and the extension bundle depends on slf4j 1.6.1 for example? > > Yes > >> >>>> >>>> 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, >> >> Should we see a problem in the scenario you're describing? > > If you load the above bundle, it will be missing the slf4j 1.6.1 > package (as the system bundle only provides 1.6.0). So the resolution > will fail. > But reading the code again, I think an exception should be thrown when > in #setupFelix() when executing the activator, right ? > >> >>>> >>>> unless you're monitoring the bundles state >>>> to check that everything has been resolved, etc... >>> >>> Plain agree. We have to fix this part. >> >> I'm not sure I fully understand this scenario yet. > > >>>> >>>> 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. >> >> >> Again do you [Guillaume] mean embedding a OSGi container when you say >> hiding? > > Yes, embedding but not giving the user access to it. > > Other possible problems are that OSGi does not work in some > environments like Google App Engine for example, because it needs > access to the file system. > > I'm quite sure I haven't fully grasped what the use case is (i.e. when > / how / who will people develop and use those bundles / extensions), > but a simple URLClassLoader would look like a way easier solution to > me when not in OSGi. If that cause problem, you could always say: > well, OSGi solves those problems so you should use it and the code is > able to leverage it. > > I guess I'm just missing the use cases to understand that this could > be a good solution, as I don't even see where the bundles loaded are > used at all > > >>> >>> Usually, we are just hiding it if the user does not have its own OSGi >>> container. >>> >> >> Please clarify. >> Thanks, >> 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/ > -- 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/
