Module system notification mechanism

[Richard S. Hall]

I think your suggestion is reasonable.

-> richard

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.
>
> - Stanley