Module system notification mechanism

[Bryan Atsatt]

Glyn Normington wrote:
>
> *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 25/06/2007 06:00:12 PM:
>
>  > It seems simple enough to put the module in a failed state if a
>  > module-init event handler throws an exception. Is this not sufficient?
>
> No, I don't think so.
>
> What state would a module be in when its module-init event is published?
> If potential consumers of the module listen for the event, then they'll
> be interested in the module being initialised (ideally meaning its
> activator has already completed successfully) and ready for use. But the
> module can't be in the initalised state if it might transition to a
> failed state if one of the event handlers calls the module's activator
> and that fails.
>
> Also, why should the failure of a 3rd party listener put the module in a
> failed state? One buggy or malicious module could impact the whole system.

Whoops. Yes, of course you are correct. I was not paying quite enough
attention here, and thinking of one of our own event models, in which
only the "module" itself can receive events. And that is very much like
the OSGi bundle activator model.

Stanley, I assume you are proposing a general mechanism in which any
code can register listeners? If so, then I have to agree with Glyn that
this is not sufficient to implement a module "activator".

>
>  >
>  > The lazy init feature sounds like a nice optimization, but doesn't
>  > strike me as a must-have. Have you seen use-cases that require it? Are
>  > they init order issues?
>
> I agree it's not a must have as JSR 291 handles that.
>
>  >
>  >
>  > (I am sensitive to your meta point here, but... If 277 is going to
>  > exist, there are some rather obvious, desirable features which it will
>  > need, just as OSGi needed them. I _don't_ like the fact that we are
>  > re-inventing rather than re-using OSGi, but that is how it has played
>  > out, despite all protestations. As long as we can still attain the goal
>  > of meaningful interoperation, it seems irresponsible to leave out
>  > features like this. And yes, we must nail down the interoperation model
>  > before we go much/any farther.)
>
> We *have* to find some way of JSR 277 being able to 'delegate' some
> responsibilities to JSR 291 rather than having to reproduce the whole
> shooting match which would literally take years (to produce something as
> good). I'd like to see JSR 277 providing some kind of basic support --
> at least the repository -- with JSR 291 providing the bells and whistles.
>
> Glyn
>
>  >
>  > Glyn Normington wrote:
>  > >
>  > > 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
> JREthat 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/
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /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/
>
>
>
>
>
>