[
https://issues.apache.org/jira/browse/KARAF-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149323#comment-13149323
]
David Jencks commented on KARAF-1009:
-------------------------------------
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.
> 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
>
>
> 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.
> To build, you need to build the /region module with -Pfetch-external to get
> the region jar in your local maven repo.
> 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
