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 20:13:32 GMT
Here are a few missing things that are supported with features and not
subsystems (api or impl), roughtly sorted from less important to more
important. The first point is really an implementation limitation, the
others are more related to the spec.

  * missing configurations support
  * missing conditional features
  * require zip packaging with multiple files, so you need tooling
  * you need to either embed the dependencies or manage a repository, you
can't a uri as we do with maven urls for most of our stuff
  * limited resolver support : computed dependencies could actually not be
used (that's the same we had with features in karaf 2.x and 3.x actually,
but now the 4.x features use a real resolver : we start from requirements
and compute the needed dependencies, the diff wrt the current state and
apply it)
  * no support for updates (related to the above) which also means no
ability to patch

Guillaume


2014-04-17 19:08 GMT+02:00 David Jencks <david_jencks@yahoo.com>:

> +1000 for removing the existing region support I added before the
> subsystems spec was ready.
>
> I don't understand why you want to do the rest.  Could you elaborate on
> what your proposal does that can't be done with spec subsystems?  Also,
> what tooling is missing for spec subsystems?
>
> I always thought that when the subsystems spec was ready karat would drop
> its proprietary features.
>
> thanks
> david jencks
>
>
> On Apr 17, 2014, at 12:56 AM, Guillaume Nodet <gnodet@apache.org> wrote:
>
> > 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
>
>

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