There has been a lot of discussion in the osgi world about isolating sets of bundles from one another by various means and we might start considering what we're going to do about this subject. I don't really expect any core isolation functionality will be implemented in geronimo -- felix, aries, and karaf are more likely spots -- but we should think about how we want to use it.
All the current ideas seem to be based on the Framework Hooks spec to be part of osgi 4.3 core. IIUC this is currently implemented in equinox 3.7 but implementation has not yet started in felix. The basic idea behind this is that you can register things into the core framework bundle resolution process that can restrict the visibility of bundles, packages, and services during resolution. So if you want to have two copies of the same bundle running at once, you register something that hides all evidence of the first bundle when the second one is being resolved. This looks like it provides a flexible framework for implementing isolation schemes, but it certainly isn't usable directly. The next step is to think about named sets of bundles, which might be called subsystems. The general idea is that within a subsystem bundles can see everything about one another but crossing the boundary of the set to other bundles visibility is restricted. You can think of different criteria and situations: 1. what can stuff in the subsystem import from outside? a. you can specify imports explicitly. b. you can automatically try to import anything not provided inside the subsystem c. I suppose you could prohibit imports. This is the top level framework, but I don't see other use for it. 2. What does "outside" mean? a. current models are that subsystems are a hierarchical tree, so imports are all from one particular containing subsystem (regarding the "framework" as top level) b. It doesn't look hard to implement a directed acyclic graph (DAG) of subsystems so you can specify the subsystems a subsystem can import from. 3. what does the subsystem make visible outside the subsystem? a. you can specify exports explicitly b. you can export nothing (aries eba isolation model) c. you can export everything (karaf features non-isolation model). 4. Are the contents of the subsystem mutable (can you add and remove bundles, and nest more subsystems inside)? a. no -- eba model b. yes -- but adding bundles doesn't change imports and exports c. yes -- and adding/removing bundles can change imports and exports. (since karaf features don't have isolation, they might work this way, but they aren't currently mutable). Since I tend to like flexibility and don't like constraining users I lean toward trying to make the "default" idea of isolation in geronimo be: - explicitly specified imports and exports - mutable subsystem contents - multiple parent subsystems. With mutable contents comes the problem of specifying which subsystem a bundle gets installed into. For a programmatic install action you can just include this info in the install action parameters, perhaps either explicitly or by consulting an environment variable (e.g. cs (change-subsystem) foo followed by install mybundle) For hot deploy scenarios I'd think you'd need something like a manifest header. This is another reason I don't like hot deploy :-) Finally there's the question of what other changes are needed in geronimo to make this plausible and useful. 1. class visibility. Right now we might be able to isolate applications from one another but it would be more difficult to isolate applications from any geronimo classes due to how we use gbeans. Gbeans kind of set themselves up and the ones that do stuff for javaee apps need access to both their own classes and the application classes in the same classloader. IIUC Jarek has done some things to construct a suitable composite classloader that we use for WABs. We might be able to leverage this for all javaee artifacts. However I think a more appropriate avenue would be to go to a bundle extender architecture where no such composite classloader is needed: the extender can directly construct the runtime container objects itself and only use the application classloader to load application classes. 2. Service visibility. (this part is completely speculative). Right now geronimo is assembled 99% using gbeans and tracking gbean references in the geronimo kernel. One important part of this is that single-valued references follow the DAG of geronimo configurations. This has been very convenient. As we move away from gbeans and managing the service references ourselves we might consider if a similar approach in osgi would be useful (2.b. above). In any case our current kernel gbean tracking is really not compatible with osgi isolation since we have no good way to reflect the osgi isolation in the kernel and make gbean visibility agree with service visibility. We can get started on bundle extenders any time.... I've been working towards a prototype for this for connectors in my sandbox.... but I doubt it will be too productive to try to install isolation until the aries prototype gets a little further along and I suspect it will need to be integrated in some way into karaf first. Comments? thanks david jencks
