Supporting OSGi Bundles in the Java Module System

[Adrian Brock]

On Mon, 2008-04-28 at 20:16 -0700, Stanley M. Ho wrote:
> 3.1.2 Constraint Checking
> A new method ModuleSystem.getModules is added to allow a ModuleSystem
> implementation to instantiate Module instances for multiple
> ModuleDefinitions in the same resolution and also to enforce
> constraints specified in these Modules. 
>   ModuleSystem class:
>       /**
>        * Returns the list of Module instances for the imports 
>        * in the same resolution for the specified importer.
>        * The returned Module instances are instantiated and initialized
>        * using the algorithm specific to this ModuleSystem.
>        *
>        * This method is called by a ModuleSystem when initializing
>        * a Module instance (importer) that imports Modules (imports) 
>        * from this ModuleSystem.
>        */
>       public List<Module> getModules(ModuleDefinition importer,
>                                              List<ModuleDefinition> imports)
>           throws ModuleInitializationException;
>   
> OSGi allows to put constraints on the importer through the metadata
> for an exported package in another bundle. The OSGi module system can
> enforce the constraints on the importer in the implementation of this
> getModules method. The importer can be a ModuleDefinition from other
> ModuleSystem. 
> 
> For example, the Apache Xerces XML parser bundle in Example 1 of
> Section 1 exports the org.apache.xerces.parsers package whose export
> definition has a "use" constraint. This export definition puts a
> constraint on the importer of the org.apache.xerces.parsers package to
> use the org.apache.commons.logging package wired to the
> org.apache.xerces.parsers package in the same resolution. The 1.0
> version of the Wombat application imports the
> org.apache.xerces.parsers bundle and the org.apache.derby bundle. The
> org.apache.xerces.parsers package will get wired to the version 1.0.4
> logging package and the constraint is satisfied and thus it can be
> wired successfully. 
> 
> Let's say a new version of the Wombat application (say version 1.2) is
> updated and it depends on an additional Apache Commons Logging utility
> which is also an OSGi bundle. 
> 
>   //
>   // com/wombat/app/module-info.java
>   //
>   @Version("1.2") 
>   @ImportModules({
>       @ImportModule(name="org.apache.xerces.parsers", version="2.6.6+")
>       @ImportModule(name="org.apache.derby", version="10.0+")
>       @ImportModule(name="org.apache.commons.logging", version="2.0+")
>   })
>   module com.wombat.app;
>   
> The bundle manifest header for the Apache Commons Logging utility is: 
>   org.apache.commons.logging:
>      Bundle-SymbolicName: org.apache.commons.logging
>      Bundle-Version: 2.0
>      Export-Package: org.apache.commons.logging; version=2.0
>   
> The 1.2 version of the Wombat application imports the
> org.apache.commons.logging bundle that violates the constraint if the
> org.apache.xerces.parsers package is wired to the version 1.0.4
> logging package but the Wombat application requires the version 2.0
> logging package. The version 1.2 of the Wombat application should fail
> to initialize due to this constraint. In other words, the getModules()
> method of the OSGi module system should throw a
> ModuleInitializationException when the OSGi module system determines
> that the constraint is violated. 

I assume the list of "importers" is intended to take the place
of Glynn's ResolutionContext?

On Mon, 2007-02-26 at 09:58 +0000, Glyn Normington wrote:
> Yes, if we want to support first class interoperation. Without
> something
> like a resolution context, I don't see how we can maximise sharing of
> dependencies between module systems. If we don't do that, we'll get
> all
> the usual symptoms of inconsistent class spaces, like class cast
> exceptions, broken loading constraints, etc. 

Assuming that is its purpose, I think the api is incomplete?

>From Glynn's original examples what is needed is to not to just look at
direct imports from the same module system.
Instead, to maximise sharing and consistency it needs to know about 
all other resolutions in a given top level resolution request.

I made a similar point on Glynn's original prototype:

On Mon, 2007-02-26 at 12:26 +0100, Adrian wrote: 
> On Mon, 2007-02-26 at 09:58 +0000, Glyn Normington wrote:
> > So the default behaviour in AbstractWireFactory.create calls
> > createLocal first so that the local name space takes precedence over
> > those of other module systems. The rationale is that the current
> > module system is like a local scope and we don't want other module
> > systems coming along and subverting the value associated with a given
> > module name that is defined locally.
> >
> 
> But equally, we want two module systems using the same module
> where possible.
> 
> e.g. If we are configured to have both a 277/291 repository
> and both define log4j:1.2.8 then the default mechanism
> should choose one of them, NOT each module system
> prefers its own.

I made another point (but I can't find the original e-mail :-) 
where I thought it probably wasn't enough to just pass
the modules in the current resolution process (i.e.
those just being resolved).

Instead, when resolving a module, there should be some
"ClassLoading Space" where the resolution can determine
all other modules that are already related due to
imports/exports (including transient ones).
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx