You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@celix.apache.org by Alexander Broekhuis <a....@gmail.com> on 2013/05/22 12:21:56 UTC
Framework API
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?
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Framework API
Posted by Pepijn Noltes <pe...@gmail.com>.
On Sat, May 25, 2013 at 12:14 AM, Gerrit Binnenmars <
gerritbinnenmars@gmail.com> wrote:
> Op 23-5-2013 9:27, Alexander Broekhuis schreef:
>
> Hi all,
>>
>>
>> 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.
>>>
>>> I'll update the bundle code to check if the bundle is the framework or
>> not,
>> and forward the call accordingly.
>>
> Alexander, as soon as things get more complicated and polymorphism is
> required again the struct with function
> pointers is preferred according to me. The readability is still
> acceptable. It is used all over the Linux kernel.
Celix already uses struct with function pointers for its services and some
other places and I agree this is also needed for more complex situations.
But for the "main" API (e.g. the OSGi api) a mapping between the (Java)
OSGi spec and C is used (see [2]).
I think this creates a clear api and enables (Java) OSGi knowledge to be
(re)used for Celix. As result I think changes to this mapping should be
avoided.
That being said, maybe it is an idea to use function pointers in the
(private) bundle struct to allow polymorphism? This way when creating a
bundle an alternative set of lifecycle functions can be provided; although
this means the bundle "constructor" signature will change.
>
>
>> A second followup question: Felix uses something they call systembundle
>> activators [1], they provide a rather clean way of embedding the
>> framework.
>> Is this something we would like to have in Celix?
>>
>> Without systembundle activators, the non-OSGi application has to use the
>> frameworkbundle to retrieve a BundleContext and work with it. This works
>> without a problem, but from a code point of view it can become messy.
>>
>> Having systembundle activators makes this cleaner, since the framework
>> takes care of calling the activators. This makes it possible to have a bit
>> more separated implementation for the non-OSGi app.
>>
>> What do you guys think?
>>
>> [1]:
>> http://felix.apache.org/site/**apache-felix-framework-**
>> launching-and-embedding.html#**ApacheFelixFrameworkLaunchinga**
>> ndEmbedding-embedding<http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-embedding>
>>
> This is a very useful extension for Celix. It can be very useful for a lot
> of legacy code.
>
Yes, very nice addition. I think this also work great for Celix.
[2] http://incubator.apache.org/celix/documentation/mapping.html
Re: Framework API
Posted by Gerrit Binnenmars <ge...@gmail.com>.
Op 23-5-2013 9:27, Alexander Broekhuis schreef:
> Hi all,
>
>
>> 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.
>>
> I'll update the bundle code to check if the bundle is the framework or not,
> and forward the call accordingly.
Alexander, as soon as things get more complicated and polymorphism is
required again the struct with function
pointers is preferred according to me. The readability is still
acceptable. It is used all over the Linux kernel.
>
> A second followup question: Felix uses something they call systembundle
> activators [1], they provide a rather clean way of embedding the framework.
> Is this something we would like to have in Celix?
>
> Without systembundle activators, the non-OSGi application has to use the
> frameworkbundle to retrieve a BundleContext and work with it. This works
> without a problem, but from a code point of view it can become messy.
>
> Having systembundle activators makes this cleaner, since the framework
> takes care of calling the activators. This makes it possible to have a bit
> more separated implementation for the non-OSGi app.
>
> What do you guys think?
>
> [1]:
> http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-embedding
This is a very useful extension for Celix. It can be very useful for a
lot of legacy code.
Greetings Gerrit
Re: Framework API
Posted by Alexander Broekhuis <a....@gmail.com>.
Hi all,
>
> 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.
>
I'll update the bundle code to check if the bundle is the framework or not,
and forward the call accordingly.
A second followup question: Felix uses something they call systembundle
activators [1], they provide a rather clean way of embedding the framework.
Is this something we would like to have in Celix?
Without systembundle activators, the non-OSGi application has to use the
frameworkbundle to retrieve a BundleContext and work with it. This works
without a problem, but from a code point of view it can become messy.
Having systembundle activators makes this cleaner, since the framework
takes care of calling the activators. This makes it possible to have a bit
more separated implementation for the non-OSGi app.
What do you guys think?
[1]:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html#ApacheFelixFrameworkLaunchingandEmbedding-embedding
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Framework API
Posted by Pepijn Noltes <pe...@gmail.com>.
Hi,
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
>