geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject osgi isolation and geronimo
Date Tue, 15 Feb 2011 23:54:53 GMT
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


Mime
View raw message