[jboss-user] [JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

[Thomas Diesler]

User development,

A new message was posted in the thread "Pluggable dependency resolver":

http://community.jboss.org/message/520557#520557

Author  : Thomas Diesler
Profile : http://community.jboss.org/people/thomas.diesler@jboss.com

Message:
--------------------------------------------------------------
Hi Kabir,
 
here is a quick describtion of how OSGi bundle resolution works.
 
For details see
 
Module Layer
http://www.osgi.org/Download/File?url=/download/r4v42/r4.core.pdf
http://www.aqute.biz/Sales/OSGi#core
 
When a bundle is http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#INSTALLED, only its constistency in terms of osgi metadata in the manifest is verified. There is no connection to other http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html established. From now on, the http://www.osgi.org/javadoc/r4v42/org/osgi/framework/launch/Framework.html is free to resolve the Bundle at any time. When a Bundle gets started (explicitly) it first becomes http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#RESOLVED and then http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#ACTIVE. For a Bundle to become RESOLVED all its required Package-Imports and other mandatory requirements must get sattisfied. If a Bundle fails to get RESOLVED it remains in the INSTALLED state and may get RESOLVED at a later time (when more requirements become available). In the transition from RESOLVED to ACTIVE the optionally associated http://www.osgi.org/javadoc/r4v42/org/osgi/framework/BundleActivator.html#start(org.osgi.framework.BundleContext) method is called. If that fails, the Bundle remains in state RESOLVED and the user may retry to start the Bundle again at some later time.
 
There are various operations that implicitly (try to) resolve a Bundle. These are
 
*  http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#getResource(java.lang.String)

*  http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#loadClass(java.lang.String)
 
and it varients. Note, that http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#getEntry(java.lang.String) does NOT trigger bundle resolution. A Bundle can also get explicitly resolved through the http://www.osgi.org/javadoc/r4v42/org/osgi/service/packageadmin/PackageAdmin.html#resolveBundles(org.osgi.framework.Bundle[]) method.
 
During bundle resolution, so called 'wires' are established between the exporter of a package and its importers. The resolver may have multiple exporters for a given package name/version to choose from and the most common case is that a Bundle contains a certain package that it may also import from another Bundle. In this case the wire may get established to the Bundle itself. It is a 'self wire'.
 
The resolver is encouraged to find the best possible solution that leads to a consistent class space. A consistent class space is one that satisfies the requirements of all importers and a given package is only exported by one and only one exporter. This can become quite complicated, especially when exported packages define a 'uses' directive. The uses directive means that all Bundles in a class space must get wired (i.e. use) the same exporter for a given package. In the face of multiple possible wiring outcomes, the uses directive helps to make more deterministic choices. Generally the resolver should aim to resolve as many as possible Bundles by walking the tree of possible wirings. In case of many unresolved (i.e. hundreds of)  Bundles this can become a very expensive operation. Equinox, disregards possible wirings after a certain level of complexity and may not find a good solution. Felix considers more possible solution but may take ages to finally return with "sorry can't do it". Currently, both Equinox and Felix work together on a standalone resolver that may be used by both frameworks (and hopefully) ours in the future.
 
Once a wiring is established, is is never changed unless the Framework is restarted or a set of Bundles is explicitly refreshed through the http://www.osgi.org/javadoc/r4v42/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]). It is important to understand that http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Bundle.html#uninstall() does NOT remove the wiring. Even after a Bundle is uninstalled it is still possible to load classes from that Bundle. This is true, unless the uninstalled Bundle was never choosen as an exporter and there is no wiring to it. In this case it can be removed from the Framework straight away.
 
Here are a few requirements that I would have on the resolver API
 
* It must be possible to resolve multiple Modules at the same time
* Resolution must be based on mandatory/optional requirements and capabilities
* Environmental capablities (i.e. OS, JDK, NativeLibraries) may influence the resolver outcome
* It must be possible to 'try run' resolution and examine the potential outcome without affecting the running system
* The MC resolver should be adaptable to the Felix standalone resolver (details still unknown)
* The resolver must have an interface to a repository (i.e. OBR) to be able to pull in unstatisfied dependencies on demand
* perhaps others that I may need to add in the future ...
 
hope that helps

--------------------------------------------------------------

To reply to this message visit the message page: http://community.jboss.org/message/520557#520557