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
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
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,
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
> wrote:
>
> Hi Casper,
>
> I guess the standard solution for restricting the imports of certain bundles
> would be to enable OSGi-Security.
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
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
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
7 matches
Mail list logo
