I think if you take a look at the aries subsystem RI, which currently doesn't include any real isolation code, you are likely to agree with me that we don't need to implement it over again in karaf.
Maybe I should explain why I think a direct region implementation will be useful even after subsystems are available. My understanding of the direction of the subsystem spec is: - a subsystem is kind of like a kar file with a single feature, and possibly some isolation information. - the isolated subsystems form a tree (each subsystem can contain any number of other isolated subsystems, but has only one parent) - to change the contents of a subsystem you have to do some kind of refresh or redeploy operation. In distinction to this, regions by themselves - form an arbitrary directed graph - are containers you can deploy stuff into. So the main existing use of isolation I'm aware of is in spring (virgo?) where there's a kernel region and an application region and stuff you deploy goes into the application region and is fairly isolated from the kernel region. I think this is a fairly useful model. I don't think you can do this with the subsystems spec; each user application can be isolated from the kernel just fine, but if you want to have more than one user application in an isolation container you need to aggregate them into an additional subsystem and deploy that. Then if you want to add a third application you have to modify this subsystem somehow. I might have missed something about how this scenario is supposed to work with subsystems, however I think the optimum situation might end up being having the ability to configure regions directly (what I implemented) and then having the ability to deploy (trees of) subsystems into these predefined regions. Another more abstruse limitation of the subsystem spec comes from the single-parent requirement for isolated subsystems. This prevents a lot of partial-shared-resources scenarios from being set up. They are a little hard to explain so I will not burden this email with an attempt to provide an example. thanks david jencks On Nov 13, 2011, at 12:11 AM, Christian Schneider wrote: > I think we should rather focus on the subsystem spec. Perhaps we could > already implement the spec like it is now and do what we think is best where > the spec is lacking. Then when the spec is finished we could > adjust our code to be fully spec compliant. So we would not have to implement > two things that do quite the same thing. > > Christian > > > Am 13.11.2011 00:49, schrieb David Jencks: >> There's been a lot of discussion about isolation in osgi, including "region" >> based isolation in virgo, composite bundle support in some versions of >> equinox, and a lot of work on the subsystems spec. Isolation in virgo and >> the aries subsystem RI appears to be going to be based on a "region" jar in >> equinox that glyn wrote for virgo. >> >> The subsystems spec looks like it's going to provide a very convenient way >> of setting up some kinds of isolation, but the plain regions jar while >> harder to configure allows a lot more flexibility. Also the subsystems spec >> won't be ready for a while and the RI is certainly lagging behind the spec >> drafts. I think it would be useful right now to have a direct region-based >> isolation solution for karaf, and it might be useful to preserve the >> additional flexibility even when subsystems are available. >> >> I've implemented a basic regions integration for karaf (trunk). See >> https://issues.apache.org/jira/browse/KARAF-1009 >> >> Some features: >> >> - regions are configured in etc/regions-config.xml. This is installed on >> first startup, changes are ignored unless you do a clean start >> >> - admin commands including region:info that shows the regions, filters, and >> which bundles are in which region. There are some more commands described >> in the jira but they are basically useful only for playing around. >> >> - features get a new "region" attribute making them install into the >> specified region >> >> - Aries RecursiveBundleTracker has been modified to work with R43 hook based >> isolation (that's what the region jar uses under the covers) so the aries >> blueprint extender (and other extenders using the RecursiveBundleTracker) >> will work on bundles in isolated regions. >> >> There's more description in the jira. >> >> As an example, I've configured the jpa and jndi features to go in the >> application region configured in regions-config.xml. The jpa feature has a >> blueprint plan and if you have up to date aries bundles you should see that >> the blueprint stuff is created properly. >> >> These console commands might be interesting to try: >> >> region:info >> bundle:list -t 0 >> feature:install jpa >> bundle:list -t 0 >> region:info >> feature:install jndi >> bundle:list -t 0 >> region:info >> >> I'd really appreciate some feedback on this. I know the admin commands are >> pretty rudimentary :-) >> >> I also know it would be pretty nice to be able to change filters once >> created. As far as I can tell so far the regions jar doesn't let you do >> this, and although I think that ability will be needed for subsystems I >> don't propose to implement it yet. >> >> Is this something we want in karaf? >> >> >> thanks >> david jencks >> > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
