On 9/16/09 11:58, Karl Pauls wrote:
On Wed, Sep 16, 2009 at 11:51 AM, Guido Spadotto<[email protected]> wrote:
Hi all,
I've tried to search this in the specs, but having some references from you
would surely help me in finding the correct solution.
The Problem: I'd like to put several type of interfaces in a single bundle.
The exposed interfaces will be of two types: "3rd party" interfaces and
"framework" interfaces.
Framework interfaces are meant to be used by other framework components,
and they expose the framework "nuts and bolts" low-level functionalities.
3rd Party interfaces are "narrower" interfaces that provide "protected"
hooks
into the framework that might be used by 3rd party service developers.
Each type of interface will reside in its own package (org.example.3p and
org.example.fw).
I'd like to make framework interfaces visible only to specific
bundles/components
of the framework environment I'm writing (and whose bundles I am in full
control of),
whilst 3p interfaces will be exported as usual (i.e. no restrictions on
their visibility).
The Question: is there an easy/correct way of achieving this in OSGi ?
I guess you are looking for security. Have a look at the
ConditionalPermissionAdmin and the related permissions defined by
OSGi. You can find an overview at:
http://felix.apache.org/site/presentations.data/Building%20Secure%20OSGi%20Applications.pdf
As Karl says, there is no real way to do this other than security.
Otherwise, you could try to approximate it with mandatory attributes. In
the future, the spec could address such use cases (e.g., through
composite bundles, so you could create a subsystem), but even then the
only way to get guarantees is with security and granting permissions.
-> richard
regards,
Karl
Which sections in the Core/Compendium Specs cover this (Release 4, Version
4.1),
if any?
Thank you
--
Guido Spadotto
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]