[jboss-dev] Modularizing JBossAS

[David M. Lloyd]

Of the top ten goals listed for AS6 (as listed here: 
http://www.jboss.org/community/wiki/JBossASTop10 ), at five will be 
directly served by modularizing the AS.  I think everyone is in full 
agreement that it's something we can do, and something we should do.  I 
want to expand on some of the details of what it would entail.

It's apparent that the Java universe is moving towards a module-based 
architecture.  The question is, how do we want to distribute our modules? 
We have two different module architectures available today.  Thomas is 
running full steam ahead on figuring out how to distribute our stuff as 
OSGi bundles, and (as far as I understand anyway) the MC module system is 
intended to be a functional superset of OSGi, which would enable us to 
eventually integrate OSGi support directly into the MC.  Neither route is 
fully developed yet though, so I'd like to put forth a few basic 
requirements for whatever module system we use.

They're listed here: 
http://www.jboss.org/community/wiki/JBossAS6ModularizationRequirements but 
I'll copy them inline.

Please comment on this thread or on the article.  Don't be afraid to 
comment even if you think it's redundant/stupid/whatever; and of course 
don't hesitate to point out any misunderstanding/stupidity on my part.

Here's the first quick draft:

    1. Most or all of the libraries distributed with JBAS should be 
repackaged as modules.
          1. This means that we'd need a way, on bootstrap, to 
"retroactively" modularize anything on the boot classpath that has to be 
available as a module at runtime.  (Note: Any ideas?)
    2. Modules will have strictly defined dependencies.
          1. This means that deployments will only "see" APIs that they 
depend on, and only the versions that they depend on.
          2. This also means that more than one version of a module can be 
present at the same time (theoretically anyway).
    3. Module bundles should *not* have to be initially scanned on startup. 
  This will be critical to keep startup time sane.
          1. We should be able to put 5000 modules in a common lib 
directory, and not one of those files will be touched until some deployment 
depends on one of them; then, only that module should be loaded, followed 
by any of its dependencies.
          2. This implies the need for some kind of ModuleLoader mechanism, 
which is similar to a ClassLoader in that it will scan the filesystem to 
load a module only when a specific module+version is requested, and it also 
implies a connection between the bundle naming convention and the module 
name (so that the loader won't have to scan a whole directory trying to 
find a specific module).
    4. For any given Class, it should be possible to identify its module 
name & version (Note: I think we can do this today in jboss-cl).

- DML