Module isolation

[Stanley M. Ho]

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