[jira] [Commented] (KARAF-1009) equinox Region support

["David Jencks (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13160581#comment-13160581 ] 

David Jencks commented on KARAF-1009:
-------------------------------------

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).
                
> equinox Region support
> ----------------------
>
>                 Key: KARAF-1009
>                 URL: https://issues.apache.org/jira/browse/KARAF-1009
>             Project: Karaf
>          Issue Type: Improvement
>          Components: karaf-core
>    Affects Versions: 3.0.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>         Attachments: KARAF-1009.diff
>
>
> 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.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira