Hi Guillaum,
see my inline comments. (and no more "devils advocate" mode ;) )
2014-04-17 13:34 GMT+02:00 Guillaume Nodet <gno...@apache.org>:
> 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.
>
>
full ack, a tree is always far easier to understand and to control.
> 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.
>
yep, sounds good and feasible
>
> 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.
>
+1, simplifies it for us as maintainer and makes the life easier for us to
explain to others ;)
> * 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
>
>
ok, like that
> So you're actually right when you describe the whole system as a
> classloader tree.
>
The only downside, as you hide certain information and might get back to
the classloader hierarchy issues you already have with a war-classloader in
a JEE app server, but that's life one has to die one sort of death :)
>
> 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.
>
This has been the first use-case that came to my mind and is fully
understandable especially with Karaf 4 now lacking internal usage of
blueprint. and it's I think the "only" real good use-case right now, cause
if we have this "too loose" on the usage layer people will be to strict on
their applications and end up in a ear like use-case.
>
> 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).
>
>
yes and no, one could think of using a single Karaf (or cellar based
cluster ;) ) as backend for a PAAS situation where this is quite usable.
No, because of what I've already seen with Virgo (spring-dm-server) some
years ago, with kernel and user land where you had a lot of issues to share
bundles, but this is a acceptable downside for using a Karaf PAAS :)
I also like the idea of defining these isolation levels within the features
descriptor.
regards, Achim
>
> 2014-04-17 13:16 GMT+02:00 Achim Nierbeck <bcanh...@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 <gno...@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
> >
>
--
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
