karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [HEADS UP] Region support in Karaf 4.x
Date Thu, 17 Apr 2014 11:34:18 GMT
Yes, you're right about a lot of things.
Regions end up creating some kind of hierarchical classloader tree similar
to JEE.
In theory, regions define a graph, not a tree, but it's quite difficult to
manage from a user pov, so limiting to a tree makes things easier imho.

Using a graph instead of a tree could be interesting, as we could isolate
features, but still use them in a graph. At a pure package level, we could
imagine you would install the spring2 and spring3 features, and another
"scoped" feature could say that it depends on spring2 and thus would not be
allowed to see spring3 bundles.  But we can achieve the same simple use
cases using a tree really.

Anyway, I have the following requirements in mind:
  * the use of regions is optional : even if the code supports it, and even
if it's enabled by default, given the deployer explicitely require to
install a feature on a given region, the default behavior would be the same
as today and all features would be installed to the root region by default.
 So unless the user explicitely requires an installation onto a different
region, the behavior would be the same.
  * unless explicitely stated otherwise in the feature <scoping> element,
regions do inherit from all their parent capabilities, so if you define an
isolated region "root/apps", any feature deployed on the root region would
be available

So you're actually right when you describe the whole system as a
classloader tree.

However, regions isolate more than just packages, especially bundle
visibility (which can be interesting when working with extenders such as
aries-blueprint and gemini-blueprint) and service visibility.

One big use case I have in mind is if you want to allow deployment of
bundles by a third party : you may want to tightly control the region so
that bundles from the third party can't see your internal stuff (and can't
mess with it) and also isolate bundles from a third party from another
(multi-tenant applications).


2014-04-17 13:16 GMT+02:00 Achim Nierbeck <bcanhome@googlemail.com>:

> Hi Guillaume,
>
> thanks for the Head-up. The first time I had contact with some sort of
> "region" was while playing around with the spring-dm-server (now Virgo) and
> tbh. I didn't like it.
> Especially this separation of kernel- and user-land for bundles been a big
> pita and quite confusing,
> the worst thing about it, I needed to install bundles twice. This is
> something I surely don't want for Karaf. We need to make sure this doesn't
> bloat everything as it did for Virgo.
>
> Besides this :)
> The idea of the regions especially for having spring2 and spring3
> applications running on the same container does seem quite tempting. Are
> bundles of the root region to be shared with the underlying region. And
> doesn't the region concept go back to a hierarchical classloader? Like what
> we have in a JEE server? (Beware I'm in devels advocate mode) While at it,
> wouldn't this mean Karaf ends up doing the same as a standard JEE server
> with the hierarchical classloader and what is the purpose of Karaf then?
> Don't we loose all the benefits of OSGi at this point, shouldn't people
> just develop EAR applications then again?
>
>
>
> regards, Achim
>
>
> 2014-04-17 9:56 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:
>
> > 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
> >
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message