ModuleDefinition construction WAS Re: Goals was: Re: Supporting OSGi Bundles in the Java Module System

Adrian Brock abrock at REDHAT.COM
Thu Jun 12 06:21:02 PDT 2008

On Wed, 2008-06-11 at 22:31 -0700, Stanley M. Ho wrote:
> Hi Adrian,
> Adrian Brock wrote:
> > My critisms of using the JSR277 repositories to do the integration
> > included:
> I want to better understand your concerns around developing 
> repositories, since I believe some of your concerns have already been 
> addressed in the draft API.

The comments I included were from discussions (a year ago)
before the current api changes, so some parts maybe out-of-date.

> > * There are already lots of orthogonal reasons for swapping
> > repository implementations
> > 
> > On Mon, 2007-02-26 at 12:26 +0100, Adrian wrote:
> >> So besides the peer/hierarchy argument there
> >> is also the problem that the repository is dealing
> >> with too many concerns.
> >>
> >> 1) ModuleDefinition construction
> The draft API provides a Modules.newJamModuleDefinition() method to 
> construct a ModuleDefinition from JAM's metadata and ModuleContent. The 
> ModuleContent abstraction enables a module archive to be stored in the 
> repository in any form under the cover. This should make it easier for a 
> repository implementation to construct ModuleDefinitions from JAM files, 
> or from other archive formats (as long as the metadata information of a 
> module can be expressed as JAM's metadata, and the content of the module 
> can be exposed through the ModuleContent abstraction).
> In your original use case in JavaEE, the appserver wants to use the 
> module system for "plain old module" wiring but also wants to define its 
> own "modules" for wars, ears, etc., and some of which looks nothing like 
> jars/jams in structure. Do you think the draft API and the ModuleContent 
> abstraction are sufficient to address the ModuleDefinition construction 
> issue you were concerned with?

I see a number of possible use cases here 
(I'll continue with appserver example):

1) Fully JSR 277

The appserver and JavaEE specs are updated to fully understand
JSR277/294. In this case, the JavaEE deployment process would 
probably make use of a JSR 277 repository.

2) Partial JSR 277

The appserver knows about JSR277/294 but the JavaEE specs
haven't been updated (or they are legacy deployments).

In this case the appserver could try to adapt the deployments
to conform to the ModuleDefinition/Content.

In this case, there probably wouldn't be a real repository
implementation, instead the "repository" would be dummy.
It would just be serving as an adapter from the old deployment packaging
and metadata to the new one at runtime.

3) Mixed

Similar to 2, but the opposite. 
The appserver knows about JSR277/294 and wants to support
.jam files as well as .jar files in JavaEE deployments.
i.e. .jam files would be unpacked from a .jar EAR deployment
and then added to the module system runtime.


I expect there are other possible uses.

The question is whether Repository is the best api
for cases (2) and (3). i.e. we implement a dummy
repository with a dummy "URL" for the source
or whether there should be a more abstract parent
class (I called it ModuleSource) that doesn't
assume a physical repository behind the scenes.

At least for cases (2) and (3) all we really want
to do is to PUSH a ModuleDefinition/Content to the
jsr 277 module system such that we can get back
a Module/Classloader with the imports resolved.
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat

More information about the jsr277-eg-observer mailing list