Hi Bryan,
Bryan Atsatt wrote:
I think the purely private repository model works fine, where the
definitions and module instances are also private.
And, as I said in the app server thread, using the private repository
approach for web-modules literally means a repository containing a
*single definition*. This may be an acceptable solution, but I want to
ensure that everyone is aware of this implication.
Sure. I think we're more or less on the same page now. ;-)
If the semantics of releaseModule() limit its use to very special
circumstances, I think it would be appropriate to capture this in the API.
Agreed.
In the spec, you rule out the use of this method against any java.* or
bootstrap repository module.
But is it ever appropriate to call releaseModule() on a Module from the
system repository? Or any public, global repository?
Most likely not, but I see your point.
I was simply exploring the possibility that this functionality only
makes sense on a private repository instance. But I don't care if we
generalize that to say that the creator should be able to control this
behavior.
If so, I'd like that to be manifest in the API somehow. I don't really
care how. As another possibility, why not expose this an attribute of
Repository, just as we do read-only status?
public abstract boolean supportsRelease();
And then document ModuleSystem.releaseModule() as a no-op or failure
when the underlying repo returns false.
This sounds reasonable. I will look into this for the next revision of
the API spec.
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?
My only remaining design concern (on the topic of isolation) is the
semantics of releaseModule(). As long as we nail down the *correct*
usage of this method, I'll be happy.
Good. I will clarify the semantics of releaseModule() in the javadoc.
Since the current design does not provide a means to determine or
control use of released modules, class duplication failures and/or large
memory leaks remain a strong possibility. As I've said from the very
beginning, we have solved this problem in our application server by
choosing to disable the class loaders of "released" modules, and it has
proven extremely useful. I would like to see this supported here as an
optional behavior.
Disabling the classloaders is a different issue. I will start a new
thread on a topic related to this issue soon.
- Stanley
