Thinking about

[JBAS-8464] Preload OSGi Resolver with selected bootstrap modules

I figured that there might be an interim solution which could get us a fair bit of footage already

Currently we have an OSGi subsystem configuration like this

        <osgi:subsystem activation="ON_DEMAND">
            <osgi:properties>
                <osgi:property name="org.jboss.osgi.system.modules">
                    org.jboss.logging, 
                    org.apache.log4j, 
                    org.osgi.core, 
                    org.osgi.compendium, 
                    org.jboss.osgi.spi, 
                    org.jboss.osgi.deployment 
                </osgi:property>
                <osgi:property name="org.osgi.framework.system.packages.extra">
                    org.apache.log4j;version=1.2,
                    org.jboss.logging;version=3.0,
                    org.jboss.osgi.deployment.deployer;version=1.0,
                    org.jboss.osgi.deployment.interceptor;version=1.0,
                    org.jboss.osgi.spi;version=1.0,
                    org.jboss.osgi.spi.capability;version=1.0,
                    org.jboss.osgi.spi.util;version=1.0,
                    org.jboss.osgi.testing;version=1.0
                </osgi:property>
            </osgi:properties>
        </osgi:subsystem>

The idea is that we add the modules identifiers defined in 'org.jboss.osgi.system.modules' as module depedencies (with re-export all) to the org.jboss.osgi.framework module, which is our core framework implementation. The ModuleClassLoader for the framework can hence see packages from these system modules.

User bundles however cannot automatically see these packages because the values for 'org.osgi.framework.system.packages' and 'org.osgi.framework.system.packages.extra' apply. As a consequence, when you want the framework to export a certain package you must add the module that provides that package AND also add the specific package to 'org.osgi.framework.system.packages.extra'

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

In the future we would like to preload the OSGi resolver (XResolver) with system XModules which provide their respective XCapabilities. These modules may already have been wired at boot time, so the resolver would need to be given the predetermined set of XWires for these modules. The current API does however not allow us to do that because (by design) the resolver is supposed to be the only entiy that determins these wires.

A future configuration could look like this

        <osgi:subsystem activation="ON_DEMAND">
            <osgi:modules>
                <osgi:module name="org.jboss.logging"/>
                <osgi:module name="org.apache.log4j"/>
                <osgi:module name="org.osgi.core"/>
                <osgi:module name="org.osgi.compendium"/> 
                <osgi:module name="org.jboss.osgi.spi"/> 
                <osgi:module name="org.jboss.osgi.deployment"/>
                <osgi:module name="jboss-osgi-common" start="true"/>
                <osgi:module name="jboss-osgi-hotdeploy" start="true"/>
            </osgi:modules>
            ...
        </osgi:subsystem>

Note, that a system module would not be treated differently to an ordinary OSGi bundle. The resolver would know about these modules and wires can be establlished between them in the same way as we do with bundles. Conceptually, the resolver would be the central entity that is tasked to maintain consistent wirings between all visible modules, such that consistent class spaces can be created.

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

The shortcut that I was thinking of was to use the latter configuration, but internally fall back to the former implementation. A system module that is already wired would be added as a module dependency to the framework (as we do already). A system module that is not yet resolved could be added to the resolver like any other deployment when it gets installed to the framework.

From the perspective of a user bundle it should not make a difference of whether the framework exports a certain package or the package is exported by a module directly. To reduce confusion we would apply the same package filtering rules that are defined on the respective system module. i.e. There would be no need to add these packages to 'org.osgi.framework.system.packages.extra' any more. This is because conceptually we see these modules installed to the framework like ordinary bundles. i.e. the define their own Export-Package ruels.

What do you think?