An installed module in the Runtime.
A module must have a unique {@link ResourceIdentity} in the Runtime.
Gravia stays out of the business of resolving module's at runtime. Every module has an associated {@link ClassLoader} when it is installed in the runtime already.Modularity must be dealt with in the layer using the Gravia runtime.
For example, a servlet container like Tomcat may choose to create one Module per web application. Multiple modules may share the same class loader or may even all have the same class loader association. This allows GRavia to run on a flat class path (e.g. a plain JUnit test)
When installed it is also assigned a {@code long} identity, chosen by the Runtime.This identity does not change during the lifecycle of a module. Uninstalling and then reinstalling the module creates a new unique {@code long} identity.
A module can be in one of six states:
- {@link State#INSTALLED}
- {@link State#RESOLVED}
- {@link State#STARTING}
- {@link State#ACTIVE}
- {@link State#STOPPING}
- {@link State#UNINSTALLED}
A module should only have active threads of execution when its state is one of {@code STARTING}, {@code ACTIVE}, or {@code STOPPING}. An {@code UNINSTALLED} module can not be set to another state;it can only be reached because references are kept somewhere.
The Runtime is the only entity that is allowed to create {@code Module}objects, and these objects are only valid within the Runtime that created them.
Modules have a natural ordering such that if two {@code Module}s have the same {@link #getModuleId() module id} they are equal. A {@code Module} isless than another {@code Module} if it has a lower {@link #getModuleId() module id} and is greater if it has a higher module id.
@author thomas.diesler@jboss.com
@since 27-Sep-2013
@ThreadSafe