Module system notification mechanism

[Glyn Normington]

Yes, but my point was that separating lifecycle out in that way would make
it harder to enforce constraints like "if a module's state is initialised,
the module's activator completed successfully".

JSR 291 solved this problem with additional module states and error
handling. It also supports lazy module initialisation triggered by the
first class load from a module. How much of this should JSR 277 re-invent?

Glyn

Bryan Atsatt <bryan.atsatt at ORACLE.COM> wrote on 22/06/2007 06:12:48 PM:

> 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/
> >
> >
> >
> >
> >
> >






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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070625/fbb1b1e7/attachment.html