Stanley M. Ho wrote:
Resend.
Bryan Atsatt wrote:
...
Stanley's idea was that a Repository implementation could return a
*copy* of a ModuleDefinition created by a different Repository. Such a
Repository would in fact form an isolation context. And caching Module
instances becomes trivial: each definition can just have one as a field.
While there are definite lifecycle issues here between such repository
instances, they are probably solvable.
And then we really *do* have an exact analogue of the loader delegation
model, in which:
Repository ~= ClassLoader
ModuleDefinition ~= Class
Module ~= Object
Isolation of classes requires different Class instances. So isolation of
modules requires different ModuleDefinition instances.
Yes, that's the basic idea for isolation. In addition, the ModuleSystem
object is the one actually handling the module instances' instantiation,
initialization, and release, so the repository implementors do not have
to be aware of most of the module runtime's complexities.
It seems to me that if we're going to follow this model, then:
1. There is a 1:1 relationship between ModuleDefinition instances and
Module instances.
2. Given #1, why does the getModuleInstance() method on ModuleDefinition
need to call through to the ModuleSystem? As it is, the ModuleSystem
must keep a separate map, which seems like overkill. The definition type
will be specific to the module system, so it can always instantiate the
correct type, and simply cache it in a field.
3. The ModuleDefinition copy operation and semantics must be defined. We
could simply implement Cloneable, or create a copy() operation. Either
way, it needs to be clear *what* is copied; I would think we would copy
all of the data *except* for the ModuleDefinitionContent.
- Stanley
