Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0
    • Fix Version/s: None
    • Component/s: karaf-core
    • Labels:
      None

      Description

      Build instructions:
      After applying the patch, run
      mvn -Pfetch-external
      in the /region module to download the region jar from eclipse and install it in your local maven repo. Then build karaf as usual (itests will fail).

      Virgo and the subsystem RI (under development) use the equinox region jar for isolation in R43 frameworks. Subsystem provides a convenient way to set up some isolation containers but is much less general than the regions jar or model allow for. It might be useful both before subsystems is available and to provide the additional flexibility to integrate region based isolation in karaf.

      the attached patch implements isolation and provides some minimal administration commands. Set up the desired region model in etc/regions-config.xml. The available commands are:

      region:info shows the structure of the regions and which region each bundle is in

      region:addbundle moves a bundle from one region (probably the root) to the specified region

      region:addfilter creates a filter between regions. AFAICT once created a filter cannot be modified.

      region:addregion adds a region

      the model in regions-config.xml is installed only on first startup: subsequent modifications will have no effect without a clean start.

      The "from" and "to" regions for a filter match the region api but seem backwards to me: a filter from R1 to R2 lets the stuff allowed by the filter in R2 be visible to R1.

      Generally the practical way to install bundles into a region is to specify the (new) "region" attribute on a feature. I've set up the jpa and jndi features to install into the application region included as an example. Previously I've modified the aries 0.4-SNAPSHOT util jar to include a recursive bundle tracker that will let the blueprint extender find blueprint bundles in all regions no matter how isolated so the jpa blueprint config should get created. If it doesn't check that your aries util bundle is up to date.

      As a convenience, filters to the region containing bundle 0 (the framework) allow everything exported by the framework.

      Currently the itests fail, I think because the new methods on R43 Bundle are hidden by a R4.2 framework api jar earlier on the classpath somewhere in pax-. I'm hoping someone who knows how pax- works can look into this.

      1. KARAF-1009.diff
        173 kB
        David Jencks

        Issue Links

          Activity

          Hide
          David Jencks added a comment -

          add region support to karaf.

          Show
          David Jencks added a comment - add region support to karaf.
          Hide
          Andreas Pieber added a comment -

          this one looks quite interesting to me; but one comment in here: the problem is that this patch will only work with eclipse active; but we've no way right now to map features to active osgi impl --> shouldn't we add some way here first before we apply that patch?

          Show
          Andreas Pieber added a comment - this one looks quite interesting to me; but one comment in here: the problem is that this patch will only work with eclipse active; but we've no way right now to map features to active osgi impl --> shouldn't we add some way here first before we apply that patch?
          Hide
          David Jencks added a comment -

          I'm not sure why you think this is tied to equinox, in fact I realize I forgot to test it with equinox, only with felix. It only uses R43 core features.

          Show
          David Jencks added a comment - I'm not sure why you think this is tied to equinox, in fact I realize I forgot to test it with equinox, only with felix. It only uses R43 core features.
          Hide
          Andreas Pieber added a comment -

          I didn't looked in it deep enough, but I though so because of the name of the issue (equinox Region) and a direct reference to org.equinox... somewhere; but if it works one felix too +1

          Show
          Andreas Pieber added a comment - I didn't looked in it deep enough, but I though so because of the name of the issue (equinox Region) and a direct reference to org.equinox... somewhere; but if it works one felix too +1
          Hide
          Łukasz Dywicki added a comment -

          Region or subsystem support looks really cool for me, especially to deploy for example webconsole twice with different extensions. However patch puts generated classes into version control. Moving external dependencies to maven repo would be also good. Currently some poms depend on eclipse.org download links.

          Show
          Łukasz Dywicki added a comment - Region or subsystem support looks really cool for me, especially to deploy for example webconsole twice with different extensions. However patch puts generated classes into version control. Moving external dependencies to maven repo would be also good. Currently some poms depend on eclipse.org download links.
          Hide
          David Jencks added a comment -

          Note that this is NOT subsystem support, the subsystem spec is not all that stable yet and support for it is very much more complicated than what I came up with.

          If by "generated classes into version control" you are referring to the jaxb model classes for the regions-config xml, I now always put jaxb classes into version control after initial generation. Eventually I always end up editing the java so it is more convenient to use and still fits the xml. This code is new so you may not see the edits I've already done . I do like to leave a profile to regenerate the jaxb classes for comparison purposes.

          Unfortunately I don't have 3 or 4 more lifetimes available to me to try to influence eclipse release policies, if Sonotype's involvement with eclipse can't get them to release to a meven repo I don't think I have much chance by myself. At least I found a plugin that can be used in a profile to download the dependency.

          Show
          David Jencks added a comment - Note that this is NOT subsystem support, the subsystem spec is not all that stable yet and support for it is very much more complicated than what I came up with. If by "generated classes into version control" you are referring to the jaxb model classes for the regions-config xml, I now always put jaxb classes into version control after initial generation. Eventually I always end up editing the java so it is more convenient to use and still fits the xml. This code is new so you may not see the edits I've already done . I do like to leave a profile to regenerate the jaxb classes for comparison purposes. Unfortunately I don't have 3 or 4 more lifetimes available to me to try to influence eclipse release policies, if Sonotype's involvement with eclipse can't get them to release to a meven repo I don't think I have much chance by myself. At least I found a plugin that can be used in a profile to download the dependency.
          Hide
          Guillaume Nodet added a comment -

          Do you have a git branch available for that ? It would be easier to review.
          I've seen you already have a github karaf repo but I don't see any interesting branch there.

          Show
          Guillaume Nodet added a comment - Do you have a git branch available for that ? It would be easier to review. I've seen you already have a github karaf repo but I don't see any interesting branch there.
          Hide
          David Jencks added a comment -

          I just set up a github branch called "region". It has an additional commit that looks for a manifest header "Region" and if present installs the bundle into the named region.

          Show
          David Jencks added a comment - I just set up a github branch called "region". It has an additional commit that looks for a manifest header "Region" and if present installs the bundle into the named region.
          Hide
          Guillaume Nodet added a comment -

          I really like this idea. On the pure technical pov, I think it would be better to move the shell/region module into region/commands and add a region/management layer for JMX to be consistent with other karaf provided services.

          The region:info command looks a bit too verbose to me and I wonder if it should only display the list of regions when launched with no informations and have parameters to get informations on a specific region (or set of regions). One thing that could be interesting too may be a way to display the region graph in a more consise way. Not sure exactly though...

          Btw, I've added the region jar into the servicemix m2 repository so it can now be found by the build.

          Show
          Guillaume Nodet added a comment - I really like this idea. On the pure technical pov, I think it would be better to move the shell/region module into region/commands and add a region/management layer for JMX to be consistent with other karaf provided services. The region:info command looks a bit too verbose to me and I wonder if it should only display the list of regions when launched with no informations and have parameters to get informations on a specific region (or set of regions). One thing that could be interesting too may be a way to display the region graph in a more consise way. Not sure exactly though... Btw, I've added the region jar into the servicemix m2 repository so it can now be found by the build.
          Hide
          David Jencks added a comment -

          I moved the commands under region/ and added a bunch of options and arguments to the region:info command as you suggested and pushed (with force) a new copy to github.

          The remaining bits before committing are I think

          • take out the region in the 2 sample features I was testing with
          • figure out what actual aries versions should be (I updated to a lot of snapshots, but I'm not sure they are correct yet. At least utils needs to be a snapshot).
          Show
          David Jencks added a comment - I moved the commands under region/ and added a bunch of options and arguments to the region:info command as you suggested and pushed (with force) a new copy to github. The remaining bits before committing are I think take out the region in the 2 sample features I was testing with figure out what actual aries versions should be (I updated to a lot of snapshots, but I'm not sure they are correct yet. At least utils needs to be a snapshot).
          Hide
          Hendy Irawan added a comment -

          I would so love to see this happen!

          Show
          Hendy Irawan added a comment - I would so love to see this happen!

            People

            • Assignee:
              David Jencks
              Reporter:
              David Jencks
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development