This document is a draft, it may (and probably will) change significantly.
- All class loading is handled by Jboss modules
- All non-ear deployments are represented by a single module
- Inside an ear:
- deployments are represented as a single module
- The combined contents of the /lib directory is represented as a single module
- By default war modules have access to /lib and all other non-war deployments
- All non-war deployments have access to /lib and all other non-war deployments
- jars in /lib jave access to other jars in /lib
- Class-Path references
- If the jar that is pointed to by a class-path reference is not accessible by default (e.g. in /lib) then the jar is turned into a module
- Transitive dependencies are handled by the deployer, not jboss-modules, so modules do not re-export any of their imports
- TODO: how do we handle references from a ejb jar to a jar in WEB-INF/lib of a war, (this should probably result in a copy of the class).
- references to jars in another deployment are supported. If that deployment is removed then the deployment will go down, if the other deployment is replaced then this deployment will come back up.
- Extension-List references
- Each referenced jar is treated as a single module (TODO should these modules be shared between deployments)
- Custom Module Configuration
- Custom module configuration will be supported. At a minimum it will support the following:
- Turn an arbitrary jar (outside of /lib) into a module, and specify it's dependencies
- Specify additional dependencies for any (or all) modules in the deployment
- Produce multiple modules from the same jar with different module configurations (e.g. one that has a dependencies on util-1.0.jar and another that has a dependency on util-1.1.jar)
- Provide a complete module configuration for any deployed module that overrides the default dependencies created by the container.