You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Casper van der Tuin <ca...@planonsoftware.com> on 2018/11/05 08:17:16 UTC
Running felix container inside another felix container
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Antw: Running felix container inside another felix container
Posted by Bruce Jackson <br...@thingstream.io>.
Or perhaps use remote services to export only the services you want to export into another felix runtime?
> On 5 Nov 2018, at 10:29, Christoph Nölle <ch...@iee.fraunhofer.de> wrote:
>
> Hi Casper,
>
> I guess the standard solution for restricting the imports of certain bundles would be to enable OSGi-Security. In this case a bundle needs a special permission to import packages from another bundle, and you can use the ConditionalPermissionAdmin service to configure the permissions. For instance, if you deploy the system bundles to the ./system folder and custom extensions to ./custom, then you could use the following permissions to a) run your system bundles without any restrictions (they have all permissions) b) restrict your customers' bundles to import the "my.api" package:
>
> allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./system/*"] (java.security.AllPermission)} "system-bundles"
> allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (org.osgi.framework.PackagePermission "my.api" "import")} "api-import"
>
> Alternatively, you could explicitly deny only certain imports to the custom bundles:
>
> deny { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (java.security.AllPermission) (org.osgi.framework.PackagePermission "my.internal.api" "import") (org.osgi.framework.PackagePermission "something.else" "import")} "critical-imports"
> allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (java.security.AllPermission)} "all-the-rest"
>
> Instead of bundle location, you can also use signer information to grant/deny permissions.
>
> Unfortunately, there are few useful resources on the topic of OSGi security available, but the spec might be helpful:
> https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html <https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html>
> https://osgi.org/specification/osgi.core/7.0.0/framework.security.html <https://osgi.org/specification/osgi.core/7.0.0/framework.security.html>
>
> To run OSGi with security enabled you need to add a file "all.policy" with content "grant { permission java.security.AllPermission; };" and specify the properties "-Dorg.osgi.framework.security=osgi -Djava.security.policy=<PATH/TO/all.policy>".
> With Felix you also need to add the bundle org.apache.felix/org.apache.felix.framework.security to your run configuration (a framework extension bundle), the latest version is 2.6.1 (works at least for Felix framework >= 5.6.10).
>
> Best,
> Christoph
>
> >>> Casper van der Tuin <ca...@planonsoftware.com> 05.11.2018 09:17 >>>
> 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 <http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
----
Bruce Jackson
CTO
bruce.jackson@thingstream.io
Antw: Running felix container inside another felix container
Posted by Christoph Nölle <ch...@iee.fraunhofer.de>.
Hi Casper,
I guess the standard solution for restricting the imports of certain bundles would be to enable OSGi-Security. In this case a bundle needs a special permission to import packages from another bundle, and you can use the ConditionalPermissionAdmin service to configure the permissions. For instance, if you deploy the system bundles to the ./system folder and custom extensions to ./custom, then you could use the following permissions to a) run your system bundles without any restrictions (they have all permissions) b) restrict your customers' bundles to import the "my.api" package:
allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./system/*"] (java.security.AllPermission)} "system-bundles"
allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (org.osgi.framework.PackagePermission "my.api" "import")} "api-import"
Alternatively, you could explicitly deny only certain imports to the custom bundles:
deny { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (java.security.AllPermission) (org.osgi.framework.PackagePermission "my.internal.api" "import") (org.osgi.framework.PackagePermission "something.else" "import")} "critical-imports"
allow { [org.osgi.service.condpermadmin.BundleLocationCondition "file:./custom/*"] (java.security.AllPermission)} "all-the-rest"
Instead of bundle location, you can also use signer information to grant/deny permissions.
Unfortunately, there are few useful resources on the topic of OSGi security available, but the spec might be helpful:
https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html
https://osgi.org/specification/osgi.core/7.0.0/framework.security.html
To run OSGi with security enabled you need to add a file "all.policy" with content "grant { permission java.security.AllPermission; };" and specify the properties "-Dorg.osgi.framework.security=osgi -Djava.security.policy=<PATH/TO/all.policy>".
With Felix you also need to add the bundle org.apache.felix/org.apache.felix.framework.security to your run configuration (a framework extension bundle), the latest version is 2.6.1 (works at least for Felix framework >= 5.6.10).
Best,
Christoph
>>> Casper van der Tuin <ca...@planonsoftware.com> 05.11.2018 09:17 >>>
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Running felix container inside another felix container
Posted by Casper van der Tuin <ca...@planonsoftware.com>.
Hi all,
I managed to run an additional OSGi container from a bundle,
ContainerBundle, so the OSGi container is running within the host OSGi
container. Both containers have their own felix (org.apache.felix.framework)
embedded. And share the osgi interfaces from org.osgi.*. However as the osgi
packages are also packed in the felix jar file I had to package the classes
from org.apache.felix.framework and the default.properties explicitly in the
ContainerBundle, instead of embedding a jar file directly from a repository
(e.g. maven).
I could not find a distribution of felix that did not contain the osgi
interface (org.osgi.*). Does anyone know if such a distribution is available
on a repository?
--
Sent from: http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Running felix container inside another felix container
Posted by David Jencks <da...@gmail.com>.
You can also construct an isolation solution using the (non spec I think) region digraph support that is used to implement subsystems. This would be much easier than dealing with the framework hooks yourself. I think subsystems will be adequate for isolation but you may find they introduce constraints on how additional bundles must be deployed that don’t work for you. However, from your description, deploying your solution in a subsystem and exporting the packages and services you want to expose for extension will meet your needs.
David Jencks
Sent from my iPhone
> On Nov 5, 2018, at 4:59 AM, Casper van der Tuin <ca...@planonsoftware.com> wrote:
>
> Hi all,
>
> Thanks for the quick answers. I will explore them to see which most fit our
> requirements.
>
> Greetings,
> Casper
>
>
>
> --
> Sent from: http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Running felix container inside another felix container
Posted by Casper van der Tuin <ca...@planonsoftware.com>.
Hi all,
Thanks for the quick answers. I will explore them to see which most fit our
requirements.
Greetings,
Casper
--
Sent from: http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Running felix container inside another felix container
Posted by Casper van der Tuin <ca...@planonsoftware.com>.
Hi all,
Thanks for the quick answers. I will explore them to see which most fit our
requirements.
Greetings,
Casper
--
Sent from: http://apache-felix.18485.x6.nabble.com/Apache-Felix-Users-f4833200.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Running felix container inside another felix container
Posted by Karl Pauls <ka...@gmail.com>.
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
<ca...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org