ModuleDefinition construction WAS Re: Goals was: Re: Supporting OSGi Bundles in the Java Module System
Stanley M. Ho
Stanley.Ho at sun.com
Fri Jun 13 17:12:36 PDT 2008
Adrian Brock wrote:
> 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.
In your example, if you want to create ModuleDefinitions from the .jar
files, there are two ways to achieve it:
1. a. Create a ModuleContent based on the content of the .jar file.
b. Generate the JAM's metadata based on information in the .jar file.
c. Construct a JAM's ModuleDefinition with the ModuleContent using
Modules.newJamModuleDefinition(). The ModuleDefinition would be
associated with the JAM module system.
2. a. Create a ModuleContent based on the content of the .jar file.
b. Create your own ModuleDefinition with the ModuleContent and use
the JAM module system as the associated module system. As long as
your ModuleDefinition exposes the appropriate metadata information
reflectively, the JAM module system would treat it like other
In either case, the JAM module system could be used to instantiate and
initialize Module/ClassLoader from the ModuleDefinition.
Creating a repository implementation is a different story. In the
current draft API, you do need to override a number of methods in
Repository in order to have a functional repository implementation. I
still think Repository is the api for module systems to find
ModuleDefinitions. The question is how we could change the API to make
it much easier for developers to create custom repository implementation.
Perhaps we should provide more useful default implementation in the
Repository's methods so developers only need to override very small
number of methods. Or perhaps what we really need is a repository
builder which allows developers to provide a set of ModuleDefinitions
and get back a basic repository implementation to use.
I'll look into the draft API to see if further simplifications can be made.
More information about the jsr277-eg-observer