Hi Bryan, Sorry, I was sidetracked in the last two days, will follow up other threads soon.
Bryan Atsatt wrote:
This use case seems to presume that the IDE can/will ensure that there is only *one* consumer of the module: itself. What if a different plugin has a dependency on it, and has already been resolved? Is the intention that the IDE will be wired into the module system deeply enough to manage this correctly?
It won't affect existing plugins that has also been initialized with the dependency. My assumption is that the IDE should know what it's doing when using the APIs.
An application server, for example, will need to keep one application from accessing the modules of another. And it must *know* that there is no sharing, so that the application lifecycles can remain independent. So we need some notion of a context. A purely private repository instance is one (probably good) possibility. Another is the wrapper Repository approach, but this requires definition copies (and management of sharing content, lifecycle, etc).
The way I see it is that the repository is the context that you want to use for isolation. The APIs allow developers only to walk up the parent repository instance from a child repository instance, but not vice versa. If the repository instance is only used in a specific domain (e.g. webapp) and the repository instance is hidden from other applications (e.g. other webapps), this would effectively hide the modules in that repository and the repository could be considered private. Whether such repository is constructed using the wrapper approach or reusing existing ModuleDefinitionContent is an implementation detail. Do you agree?
Regardless of what approach we take, the releaseModule() idea is too simplistic. Having originally created the detach() method, thinking along similar lines as you are with the plugin case, I do understand the idea; I just no longer think it is sufficient :^). The only "safe" time to release a module is when there are *zero* importers, and, even then, you must hide/release atomically, ensuring that no new imports spring up during the operation.
Releasing a module simply means that its reference is released from the module system's cache; it does not affect any existing importer. Also, hide and release does not need to happen atomically - I think hiding it first would be sufficient to prevent new imports to be resolved, but I'll need to double check it with the RI. Note that I'm not arguing the releaseModule() approach is perfect, but I do think this is a use case that we can ignore; I would welcome better suggestion to handle this.
Other than Module instances, what other "runtime information" is there to keep track of? Caches of exported packages?
The Module instances that have been initialized, the ModuleDefinitions that are being instantiated and the corresponding Module instances that are being initialized (could be triggered simultaneously from multiple threads), and the ModuleDefinitions that have been disabled (e.g. the repository has been shutdown and no new Module instance should be created).
For example, if we were to eliminate the releaseModule() method (in favor of some more complete mechanism), then there really is always a 1:1 for Module:ModuleDefinition, and the model is simple and obvious. (And therefore a field cache *could* be used).
To keep this discussion focus, I think we could assume Module:ModuleDefinition is 1:1 for now. releaseModule() is just a special case. That said, even if the relationship is 1:1, it still doesn't mean we *should* put the state in ModuleDefinition, see above. ;-)
So, in effect, we have 100% *private repository* instances. I've been thinking that we need an intermediate somewhere between a shared/public repo instance and an entirely private one, but... that now strikes me as too fuzzy, and I can't see a real use case :^) So an application server would have to create, say, a private LocalRepository instance to hold the modules of a single application. And it would have to ensure that no other application could get it's grubby paws on that repository instance. Ok. That works for me. And it eliminates the need for cloning AND for releaseModule(): 1. Any given Repository instance is either 100% shared or 100% private, with *no* in-between. 2. The lifecycle of a shared repository instance is that of the process. 3. The lifecycle of a private repository instance is entirely up to the creator of that instance.
I agreed that distinguishing the repository instances for sharing or private usages is more easy to understand, but the notion of shared and private really depends on the usage context, and it's not an attribute of the repository itself. Suppose there is a repository with two child repositories; this repository would be considered "shared" from the perspective of the modules in the child repositories, but this repository might still be considered private from the other applications in the same JVM. I think your first three points can be combined as follows: 1. Any given Repository instance could be used for sharing or private purpose. 2. The lifetime of a repository instance is managed by its creator.
4. The lifecycle of a ModuleDefinition/Module is at most that of the enclosing Repository instance, and at least is bounded by install/uninstall (no finer granularity).
Yes.
It does leave open the issue of dependencies *within* a private repository. The simple model would be to treat the entire repository as atomic, with any change requiring a new Repository instance. This is probably too simplistic, however. In an EE app, web-modules are supposed to be isolated from each other and from other parts of the app (ejb, connectors, etc.). So this requires either a further partitioning of the app into multiple repositories, or some form of access control.
The web-modules should probably be in its own repository if isolation is needed. There is no access control for ModuleDefinitions - accessibility of a ModuleDefinition is the same as visibility of ModuleDefinition; this is also a very different issue. I think we should focus our discussion on using repository instance for isolation unless we find this approach insufficient.
Further, it is possible to re-start or re-deploy/re-start only a single web-module, *without* restarting the rest of the app. The re-start case could use releaseModule(), though a "real" stop method would be preferable. But this is a very special case in which the specs essentially dictate the possible dependencies between modules. In the general case where the dependencies are not dictated, releaseModule() is problematic. The re-deploy case would use uninstall/install (but would still like stop!).
Whether the solution is stop() or releaseModule(), it still shows that we need to support the use case of long-lived repository with short-lived modules. Do you agree?
If you *really* want the releaseModule() functionality, I would suggest that we introduce a PrivateRepository type, and support release *only* on that type.
The notion of private or shared depends on the usage context of the repository instance, so it won't be appropriate to surface the concept at the API level. Bryan, there are many topics in this thread, but I think what you really want is to discuss the notion of module isolation. As we discussed so far, I think we all agreed that repository is the appropriate context to make module isolation possible. Could you summarize any outstanding design concern you have with this approach in a paragraph or two? Thanks, - Stanley
