Hi Casper,

it sounds like you are trying to create a subsystem. There is a
solution for this in the compendium spec namely, [0]. There is an
implementation that (AFAIK) works with felix in [1].

That said, if that is not applicable in your case (e.g., you want even
stronger isolation), it should be possible to install the framework
wrapped in a bundle - however, you would need to import the org.osgi.*
packages from the the outside and set the framework bundle parent of
the embedded framework to "framework".

Ultimately, if all you want is hide a couple of packages from a couple
of bundles you might want to explore using hooks to hide packages
and/or bundles from other bundles (see [2] and/or [3]).

Which approach serves you best really depends on what your use-case
actually looks like. The hooks probably are the most lightweight (but
most limited and need you to implement the hidding), the subsystem the
most convenient (but more heavyweight then a simple hook), and the
embedded framework provides the strongest isolation (at the cost of
running a complete framework again and that you have to set it up
correctly yourself).

Hope that helps, feel free to ask if you need the embedded framework
and run into problems.

regards,

Karl

[0] https://osgi.org/specification/osgi.cmpn/7.0.0/service.subsystem.html
[1] http://aries.apache.org/modules/subsystems.html
[2] https://osgi.org/specification/osgi.core/7.0.0/framework.resolverhooks.html
[3] https://osgi.org/specification/osgi.core/7.0.0/framework.bundlehooks.html
On Mon, Nov 5, 2018 at 9:17 AM Casper van der Tuin
<casper.vandert...@planonsoftware.com> wrote:
>
> Hi Felix users,
>
> Our solution consists of a set of bundles running in an Felix container
> (Host). We want to open up our part of API for other teams to extends the
> solution with additional bundles. As these should not be able to import all
> the exports from the other bundles and platform, the idea was to have have a
> bundle startup another felix container (Extension) and only export the
> packages of our open API for bundles running within this container. However
> when protoyping this we ran into the issue that the bundles running within
> the Extension container will use the class loader from the Host container
> instead of the class loader from the Extension container. Which could make
> sense as the Felix classes are contained on the Host.
>
> We also tried to include the felix jars inside the Extension bundle (to have
> the complete felix in the Extension bundle class loader). Unfortunately this
> blokced starting up the bundle, as the Activater instantiated in to startup
> the Extension bundle is now not created in the same classloader as the where
> it is used in the Host container, resulting in a class cast exception.
>
> Does any one have an idea on how to solve this issue, i.e. so that bundles
> runnning in the Extension container will load classes from the class loader
> of the Extension container bundle? Or have any other solution to restrict
> the imports of some of the bundles running in the Felix container?
>
> Greetings,
> Casper
>
>
>
> --
> Sent from: 
> http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>


-- 
Karl Pauls
karlpa...@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to