Module system notification mechanism

[Bryan Atsatt]

I think that is part of Stanley's point here: the module system isn't
responsible, as it merely generates the events. Some *other* system
could then take on lifecycle based on these events.

Glyn Normington wrote:
>
> Hmmm. I thought so too (apart from reinventing the OSGi lifecycle event,
> of course), but I wonder if the module system needs to be directly
> responsible for driving an activator in case it fails to terminate (in
> which case the module needs to enter some kind of error or inactive state)?
>
> Glyn
>
> *"Richard S. Hall" <heavy at UNGOVERNED.ORG>* wrote on 22/06/2007 01:21:48 PM:
>
>  > 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
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>