Reminder: region is a concept which allows partitioning the OSGi framework
between multiple defined regions and control the visibility of bundles,
packages and services while crossing regions. This allow the same bundle
to be deployed in two different regions if the regions can't see each other
(that's simplifying a bit, but you get the idea).
Unless I'm wrong, support for regions in Karaf 3.x is very limited and
while we have a few commands to view and operate on regions. Currently,
the region where a feature is deployed has to be written in the feature
descriptor (which makes deploying the same feature in 2 different regions
quite difficult) and there's no option for sharing policies between regions.
I've recently added support for Aries Subsystems in master. While
Subsystems could theoretically fulfil our needs, we still have the same
problems than with applications: i.e. it's totally unmanageable without
tooling.
What I'd like to do, is get rid of the current region support to have the
feature service more aware of regions. The idea is to have the following:
* a "root" region
* multiple user created child regions for isolation (import everything
from the parent, but share nothing) as a tree
Those regions are organized in a tree:
root
root/container1
root/container2
root/container2/spring2
root/container2/spring3
When installing / uninstalling features, the user will have to provide the
region path in which the new features should be added or removed.
By default, features would be flattened, i.e, bundles are deployed directly
in the region, however, features can specify a custom sharing policy so
that the internal (services and packages) is hidden and not visible outside
of the region. For example, the aries-proxy could be defined with the
following:
<feature name="aries-proxy" description="Aries Proxy"
version="${project.version}">
<bundle dependency="true"
start-level="20">mvn:org.ow2.asm/asm-all/${asm.version}</bundle>
<bundle dependency="true"
start-level="20">mvn:org.apache.aries/org.apache.aries.util/${aries.util.version}</bundle>
<bundle
start-level="20">mvn:org.apache.aries.proxy/org.apache.aries.proxy.api/${aries.proxy.api.version}</bundle>
<bundle
start-level="20">mvn:org.apache.aries.proxy/org.apache.aries.proxy.impl/${aries.proxy.version}</bundle>
<capability>
service-reference;effective:=active;objectClass=org.apache.aries.proxy.ProxyManager
</capability>
<scoping>
<export namespace="osgi.service">
(objectClass=org.apache.aries.proxy.ProxyManager)
</export>
<export namespace="osgi.wiring.package">
(|(osgi.wiring.package=org.apache.aries.proxy)(osgi.wiring.package=org.apache.aries.proxy.*))
</export>
<import namespace="org.eclipse.equinox.allow.all">
(|(!(all=*))(all=*))
</import>
</scoping>
</feature>
The <scoping> element defines a custom policy. In the above case, the only
thing exported from the region is the org.apache.aries.proxy.* packages
and the org.apache.aries.proxy.ProxyManager service. The region imports
everything.
This is really just an example and while the syntax is what i'm
experimenting with now, the idea is to simplify it so that the user would
write "package", "service", "all" and with dedicated elements to help.
Those scoped features will also create regions automatically, so that the
above when deployed into root/apps1 would create a child region
/root/apps1/aries-proxy-4.0.0-SNAPSHOT.
The features service will be responsible for computing the regions and
which and where bundles need to be deployed using the OSGi resolver.
Anyway, I'm still experimenting, but I wanted to give a heads up on this
point.
Cheers,
Guillaume Nodet
