Module system notification mechanism

[Bryan Atsatt]

Stanley M. Ho wrote:
> Hi JSR 277 experts,
>
> Since we have been discussing some issues around the module instances'
> lifetime lately, I think it's probably a good time to bring up a related
> topic for discussion.
>
> As I reviewed the feedbacks from the EDR comments, from our previous
> discussions, as well as from my discussions with the teams in SE and EE,
> there were a few suggestions related to the module instances' lifetime:
>
> 1. The module system shall provide a way to monitor various events, e.g.
> module initialized, module released, etc.
> 2. The module system shall allow a module to have activator code. The
> activator code would be executed right before the module is fully
> initialized and when the instance is released.
> 3. A module shall have a way to be stopped.
>
> Having these suggestions don't mean we have to do all of them, and I
> would like to get your inputs.
>
>
>  From my perspective, having a way to monitor module system's events
> (i.e. #1) seems very reasonable and useful, especially the use cases are
> very common. In fact, many teams in SE have expressed the needs in
> monitoring the module system's events in their class libraries in some
> degrees, so these libraries would react and behave appropriately. There
> are also other class libraries sitting on top of the JRE that have
> similar needs.
>
> For #2, this is a use case I gathered from EE, and this would be used
> mainly for registering and unregistering services when a module has been
> initialized or is released. Not that I think this is unimportant, but I
> am not yet convinced this is something we need to support directly at
> the module system level. For instance, if the module system notification
> mechanism (i.e. #1) is available, it should be possible for the EE
> server (or other apps that require similar functionality) to build a
> simple activator layer on top of the module system.
>
> For #3, the use case is that some EE servers might want to have the
> ability to "stop" a module by disabling the module's classloader when
> the module instance is released. In general, disabling a classloader is
> an uncommon and dangerous operation to perform, and it also violates the
> current classloading spec. While I agreed we should make this use case
> possible, I don't think this is something we want to push into the
> module system.; I believe there are alternatives we could consider to
> achieve the same result. For example, suppose there are APIs available
> to disable a classloader (might come from the classloading project) and
> the module system notification mechanism (i.e. #1) is available, it
> should be possible for the EE servers to hook into the notification
> mechanism, and disable the specific classloader it wants when a module
> instance is released from the module system.
>
>
> To keep things simple, I suggest we should support #1, and I hope this
> should be sufficient to enable other applications (e.g. EE servers) to
> support #2 and #3. I would like to hear what your thoughts are.

As long as there is some API support for disabling the loader, I'm fine
with this approach.

However, this is not a feature I would ever advocate adding to
java.lang.ClassLoader(!), since it really only makes sense in the
context of a managed loader. In a managed environment with a true
lifecycle, it is important to be able to *find* ongoing uses of a
supposedly stopped module. The only way we've ever been able to do that
is to ensure that any use of such a loader will cause an exception to be
thrown.

We have had great success with this model in finding code that does not
participate correctly in the container lifecycle. The most common case
is threads that aren't stopped when they should be. Leaked references
are another huge headache.

>
> - Stanley
>