Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundle: to manifest

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

You are giving me major deja vu wrt the parallel conversation
going on in the osgi-dev list...  Lets leave the bulk of this discussion
there as I think it is of general interest.  I'll comment on a few
things here just for fun but there is more detail in my earlier response
on osgi-dev

David Kemper wrote on 03/28/2006 05:54:33 PM:

> Jeff,
> 
> You write that nested JARs in a packed bundle are extracted to the
 
> file system.  Could you elaborate?
>
> For example, where are they extracted, when,
and by what layer?

Nested JARs are extracted on demand by the framework
(in around the classloaders).  They are cached in the "OSGi bundle's
configuration area".  Specifically, something like
        <eclipse locatoin>/configuration/org.eclipse.osgi/bundles
they are persisted across runs and garbage collected
as bundles are updated/uninstalled.  There is Equinox API available
to extract files on demand. See the 
        org.eclipse.osgi.service.urlconversion.URLConversion

service.

> I've been wondering about the performance implications
in both time  
> and resources between two polar opposites of runtime approach (I know
 
> this description is a bit crude):
> 
> 1) The Eclipse model, where the update configurator installs all  
> bundles in the bundle store, and then relies on the application  
> configuration (perhaps with the extension registry) to bring the  
> system up.

I mentioned this in the other list but it is worth
repeating. update.configurator, by default, installs all the bundles it
can find.  However, if you ship a crafted, more restricted configuration,
only those bundles will be installed/used.

> 2) The OSGi model, where some external operator
process installs and  
> starts certain bundles whose runtime state and start level are  
> persisted across invocations.

Depending on how many bundles you may have in one
configuration, this may or may not be an issue.  We have thousands
in one configuration so are not able to start them all or even really figure
out which ones need to be started for any given case.  The same configuration
may be run on many different data sets (e.g., workspaces) requiring that
different bundles be activated.  As a consequence, we ahave implemented
a lazy start mechanism that starts bundles the first time they try to load
a class.  This is nice because you may have 5000 bundles on disk,
1500 in the running configuration and only 129 of those actually needed
for the current dataset/situation. Only those plugins that need to be activated
are activated.  

Further, the set of bundles active in one session
is not necessarily the right set to be active in the next.  Say in
our scenario the user starts Eclipse and does some PDE work.  PDE
is activated (either lazily or say you had a smart agent that could figure
it out).  Then shutdown and restart the same configuration.  The
PDE views may not be open and hte user may not do any PDE work i nthe new
session.  So if the bundle activation was persisted, we would needlessly
activate the PDE bundles in the second session.

> In my use case I want to have a single bundle
store with tens/ 
> hundreds/thousands of bundles, including multiple versions of the
 
> same bundle, and have multiple runtime processes use the bundle store
 
> concurrently.  The primary goal of this use case is to leverage
the  
> OSGi dependency metadata and methodologies to componentize our many
 
> overlapping runtimes.  However, I don't see this use case discussed--
> it is always a single runtime tied to a single bundle store.
> 
> - It would be a waste of space if each runtime configuration would
 
> maintain a separate cache of these nested JARs.  There may be
disk  
> locking implications if multiple runtimes share the same cache.

Extracted JARs are maintained in separate caches specific
to a congiuratoin.  This is an issue we need to address.  

> - If each runtime uses the update configurator,
how much processing  
> is wasted if each runtime uses only a small subset of all the bundles
 
> in the bundle store, but all are installed for each runtime?

update.configurator realy only does work on the first
run of a configuration and only then if the configuration is not defined
(e.g., there is no platform.xml file).  Subsequent runs work out of
cached info and, for example, the bundle manifests are not even read.  In
your scenario you just want ot look at pre crafting your configuration
definitions.

> Feel free to move this to a different thread,
as it is more related  
> to your extraction comment than the unpack-bundle manifest entry.
 I  
> also have related questions about how to best express internal  
> dependencies (e.g. Class.forName() and service provider support) that
 
> I've asked on the osgi-dev mailing list.  Do you also monitor
that  
> list?  (See Indirect Dependencies in OSGi/Equinox.) I want to
be a  
> good citizen and not cross-post...

I am on both lists.  The general interest stuff
should to there.  Equinox specific questions here though some amount
of cross-project information exchange would be useful in the osgi-dev list.

Jeff