Embedded Felix

[Asaf Lahav <as...@primagrid.com>]

Hi everybody,

 

I am running Felix as an Embedded OSGi framework.

What would be the best way for components outside of the OSGi boundaries to
consume OSGi bundles and service references?

In other words, would it be bad design to maintain a singleton instance of a
context handle I get in my custom activator?

If it is, what would be a better design?

 

Thanks in advance,

Asaf

Re: Embedded Felix

["Richard S. Hall" <he...@ungoverned.org>]

Felix Meschberger wrote:
> Hi Asaf,
>
> The main problem you would probably face when getting your hands on
> something inside the OSGi framework is ClassLoading issues: You will 
> have to
> use a class (usually and interface) which is loaded from a class laoder
> commoner to both the OSGi framework and the "outer world".
>
> On the other hand, you might want your inside objects make themselves 
> known
> to the outside world through - for example - a bridge service, which is
> registered by a BundleActivator given to the Felix constructor. This 
> is how
> the Equinox HttpService to Servlet bridge works.

To be precise, you don't pass in BundleActivator instances to the Felix 
constructor, but to Felix.start().

Regardless, this is the appropriate way to embed Felix and get access to 
the System Bundle context object, because each passed in BundleActivator 
instance is treated as an extension of the System Bundle, where start() 
and stop() on each will be invoked when the System Bundle is started and 
stopped, respectively.

This is the approach for your host application (i.e., the embedding 
application) to get a context to interact with the framework and any 
installed bundles/services, such as installing/removing bundles or 
using/providing services.

All is not roses however, there is a catch. If the host application 
wants to use services from bundles or provide services to bundles, the 
service interface classes must come from the class path so that the host 
application and the bundles use the same class definitions. As Felix 
points out elsewhere, you can use the org.osgi.framework.system.packages 
property to export packages from the class path via the System Bundle.

There is one alternative, which is if you just want to use services in 
the host application, you can instead use reflection to invoke service 
methods, then the host application does not need access to the class 
definitions at all.

-> richard


>
> The details - as always - depend on what exactly you want to achieve.
>
> Anyway, I would not hold on to the BundleContext given to an Activator 
> for
> this.
>
> Hope this helps a bit.
>
> Regards
> Felix
>
> On 4/11/07, Asaf Lahav <as...@primagrid.com> wrote:
>>
>> Hi everybody,
>>
>>
>>
>> I am running Felix as an Embedded OSGi framework.
>>
>> What would be the best way for components outside of the OSGi boundaries
>> to
>> consume OSGi bundles and service references?
>>
>> In other words, would it be bad design to maintain a singleton 
>> instance of
>> a
>> context handle I get in my custom activator?
>>
>> If it is, what would be a better design?
>>
>>
>>
>> Thanks in advance,
>>
>> Asaf
>>
>>
>

Re: Embedded Felix

[Felix Meschberger <Fe...@day.com>]

Yes, by listing such packages in the "org.osgi.framework.system.packages"
property given to the Felix constructor, you may make external packages
visible inside the framework and hence use and share objects created from
those classes.

Regards
Felix

On 4/11/07, asaf.lahav <as...@gmail.com> wrote:
>
> Isn't it possible to specify via the "Import-Package" configuration
> element
> which packages are to be loaded from the underlying class loader/bundle
> class loader?
>
> -----Original Message-----
> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
> Meschberger
> Sent: Wednesday, April 11, 2007 7:42 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Embedded Felix
>
> Hi Asaf,
>
> The main problem you would probably face when getting your hands on
> something inside the OSGi framework is ClassLoading issues: You will have
> to
> use a class (usually and interface) which is loaded from a class laoder
> commoner to both the OSGi framework and the "outer world".
>
> On the other hand, you might want your inside objects make themselves
> known
> to the outside world through - for example - a bridge service, which is
> registered by a BundleActivator given to the Felix constructor. This is
> how
> the Equinox HttpService to Servlet bridge works.
>
> The details - as always - depend on what exactly you want to achieve.
>
> Anyway, I would not hold on to the BundleContext given to an Activator for
> this.
>
> Hope this helps a bit.
>
> Regards
> Felix
>
> On 4/11/07, Asaf Lahav <as...@primagrid.com> wrote:
> >
> > Hi everybody,
> >
> >
> >
> > I am running Felix as an Embedded OSGi framework.
> >
> > What would be the best way for components outside of the OSGi boundaries
> > to
> > consume OSGi bundles and service references?
> >
> > In other words, would it be bad design to maintain a singleton instance
> of
> > a
> > context handle I get in my custom activator?
> >
> > If it is, what would be a better design?
> >
> >
> >
> > Thanks in advance,
> >
> > Asaf
> >
> >
>
>

RE: Embedded Felix

["asaf.lahav" <as...@gmail.com>]

Isn't it possible to specify via the "Import-Package" configuration element
which packages are to be loaded from the underlying class loader/bundle
class loader? 

-----Original Message-----
From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
Meschberger
Sent: Wednesday, April 11, 2007 7:42 PM
To: felix-dev@incubator.apache.org
Subject: Re: Embedded Felix

Hi Asaf,

The main problem you would probably face when getting your hands on
something inside the OSGi framework is ClassLoading issues: You will have to
use a class (usually and interface) which is loaded from a class laoder
commoner to both the OSGi framework and the "outer world".

On the other hand, you might want your inside objects make themselves known
to the outside world through - for example - a bridge service, which is
registered by a BundleActivator given to the Felix constructor. This is how
the Equinox HttpService to Servlet bridge works.

The details - as always - depend on what exactly you want to achieve.

Anyway, I would not hold on to the BundleContext given to an Activator for
this.

Hope this helps a bit.

Regards
Felix

On 4/11/07, Asaf Lahav <as...@primagrid.com> wrote:
>
> Hi everybody,
>
>
>
> I am running Felix as an Embedded OSGi framework.
>
> What would be the best way for components outside of the OSGi boundaries
> to
> consume OSGi bundles and service references?
>
> In other words, would it be bad design to maintain a singleton instance of
> a
> context handle I get in my custom activator?
>
> If it is, what would be a better design?
>
>
>
> Thanks in advance,
>
> Asaf
>
>

Re: Embedded Felix

[Felix Meschberger <Fe...@day.com>]

Hi Asaf,

The main problem you would probably face when getting your hands on
something inside the OSGi framework is ClassLoading issues: You will have to
use a class (usually and interface) which is loaded from a class laoder
commoner to both the OSGi framework and the "outer world".

On the other hand, you might want your inside objects make themselves known
to the outside world through - for example - a bridge service, which is
registered by a BundleActivator given to the Felix constructor. This is how
the Equinox HttpService to Servlet bridge works.

The details - as always - depend on what exactly you want to achieve.

Anyway, I would not hold on to the BundleContext given to an Activator for
this.

Hope this helps a bit.

Regards
Felix

On 4/11/07, Asaf Lahav <as...@primagrid.com> wrote:
>
> Hi everybody,
>
>
>
> I am running Felix as an Embedded OSGi framework.
>
> What would be the best way for components outside of the OSGi boundaries
> to
> consume OSGi bundles and service references?
>
> In other words, would it be bad design to maintain a singleton instance of
> a
> context handle I get in my custom activator?
>
> If it is, what would be a better design?
>
>
>
> Thanks in advance,
>
> Asaf
>
>