directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: OSGi startup and shutdown problems
Date Wed, 11 May 2011 15:03:39 GMT
What we've done for  Camel for example is to allow those libraries to
leverage OSGi if deployed in OSGi and default to a basic mode in other

For Camel, components can be create by users (though I guess it's the
same here, not average users).  Camel can discover components using a
pluggable discovery mechanism.  When deployed in OSGi, Camel
automatically select an OSGi aware discovery mechanism that will be
able to look into existing bundles for such components (well, it's in
reality slightly more complicacted, but thats the idea).   When in a
non OSGi environement, the default discovery mechanism just scans for
META-INF/services/xxx which define camel components.

The idea here is that if the user wants to use OSGi, he'll be able to
use the OSGi modularity layer and dynamism to deploy things at runtime
and all the OSGi goodness.   Else, we just use a very simple and basic
things that works very nicely in a flat classloader.

On Wed, May 11, 2011 at 16:55, Alex Karasulu <> wrote:
> On Wed, May 11, 2011 at 5:14 PM, Guillaume Nodet <> wrote:
>> On Wed, May 11, 2011 at 15:42, Alex Karasulu <> 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
>> > <>
>> > wrote:
>> >>
>> >> On 5/11/11 10:47 AM, Guillaume Nodet wrote:
>> >>>
> SNIP ...
>> > 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 goal was not to grant programatic access to the OSGi container. The goal
> was to just expose a directory where the user can drop bundles and on
> startup they would be used to extend the codec.
> SNIP ..
>> >>>
>> >>> 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
> Agreed if a bundle supplying the 1.6.1 SLF4J API is not provided we'll get
> an exception from the container. However if the 1.6.1 API is provided in the
> bundle loading directory it should work just fine.
> However this is not that realistic of a situation because users that are
> going to use the LDAP API in this standalone scenario to extend it will have
> to use a specific version of the LDAP API and develop their
> extensions/plugins according those dependencies. Let's step through the
> process:
> 1). The user of the API wants to extend the codec in the LDAP API to handle
> the encoding and decoding of Foo extended operations present specifically in
> Bar LDAP server.
> 2). User creates a Maven project to create the Foo extended operation codec
> plugin including the dependency for the LDAP API version they're working
> with. Naturally they would use the SLF4J API dependency that the LDAP API
> version uses.
> In this case the aforementioned scenario does not result. The plugin for the
> Foo codec extension bundle would naturally have to follow the dependencies
> used by the LDAP API.
>> > Again do you [Guillaume] mean embedding a OSGi container when you say
>> > hiding?
>> Yes, embedding but not giving the user access to it.
> OK I see, we do not intend to give the user access to the container. Is
> there some reason why you think we should grant user access to the
> container?
>> 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.
> Good point. This might be a good reason to just avoid using OSGi here.
>> 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.
> This decision is really about a tradeoff. The codec needs the ability to
> allow users to extend it to handle new extended req/resp pairs and controls.
> The server and studio exist in OSGi environments where there's no problem
> with using OSGi bundles for the modularity mechanism. Plus when used in
> these two scenarios, the LDAP API extensions can be dynamically loaded,
> unloaded and/or have new versions loaded, and this is a capability is
> appealing.
> The tradeoff problem appears when the LDAP API is used standalone outside of
> these environments in a client application or with some command line tool
> for ldap clients. So having OSGi bundles for codec extensions, how do we
> re-use those extensions in the standalone scenario?
> The simple class loading mechanism should work just fine with the plugin
> bundles defaulting to regular jars, and this is how the standalone version
> of the codec factory can work while the OSGi version can be used in the
> ApacheDS and Studio use cases.
> I'm starting to think the classloader based mechanism might be best for
> standalone usage.
>> 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
> The plugin bundles do not contain any services. The activators of the plugin
> bundles simply register classes in the plugin bundle with the main service
> exported by the host application: the codec factory service.
> Looking at this big fat mess a good rule of thumb is starting to emerge:
> Do not embed OSGi containers in APIs, because you cannot be sure of the
> environments in which that API will be used.
> The best way to proceed would be to expose a means
> to programmatically register new extension components with the API, and
> leave the mechanism to load and register the plugin components outside the
> API to be handled by some other component.
> Thoughts?
> Regards,
> Alex

Guillaume Nodet
Open Source SOA

Connect at CamelOne May 24-26
The Open Source Integration Conference

View raw message