[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundle: to manifest

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

> 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.