celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Framework API
Date Wed, 22 May 2013 12:08:07 GMT

On Wed, May 22, 2013 at 12:21 PM, Alexander Broekhuis <a.broekhuis@gmail.com
> wrote:

> Hi all,
> I am looking into some code changes for embedding Celix in existing
> application. To achieve this the API of the framework needs to reorganised
> a bit. While this is fairly simple, I run into the following:
> In OSGi (Felix as example) the framework also implements the Bundle
> interface. So Felix implements Framework and Bundle. The Framework provides
> 2 methodes for initializing and stopping whereas the Bundle interface
> provides all other methods (stop, start, install bundle etc). Since in
> Celix we do not have something like polymorphism this won't work.
> Currently this is solved by duplicating the start/stop method in the
> framework itself and using an almost empty Bundle for the framework. The
> framework functions are used by the launcher and not the bundle_*
> functions. For embedding I want to make this a bit cleaner by using the
> Bundle functions for the launcher (and embedding).
> To solve this I can come up with the following:
> * There is already an almost empty bundle instance for the framework
> * This instance can be updated a bit so it has more information
> * Update the bundle functions to check if the bundle instance is a real
> bundle or the framework. If it is the framework, forward the calls to the
> framework specific implementations, if not, handle as a bundle.
> I prefer not to use struct inheritance, even though it will work, I think
> it makes things unclear.
> Does anyone have a cleaner/other solution? Or any objections to this?

I don't have any objections to this.
I also don't see a cleaner solution without resolving to structs with
functions pointers or struct inheritance. struct inheritance you already
mentioned and for structs with functions pointers will make thinks - in my
opinion - also unclear.

> --
> Met vriendelijke groet,
> Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message