<br><font size=2 face="sans-serif">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".</font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br><font size=2 face="sans-serif"><br>
Glyn</font>
<br>
<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 22/06/2007 06:12:48 PM:<br>
<br>
> I think that is part of Stanley's point here: the module system isn't<br>
> responsible, as it merely generates the events. Some *other* system<br>
> could then take on lifecycle based on these events.<br>
> <br>
> Glyn Normington wrote:<br>
> ><br>
> > Hmmm. I thought so too (apart from reinventing the OSGi lifecycle
event,<br>
> > of course), but I wonder if the module system needs to be directly<br>
> > responsible for driving an activator in case it fails to terminate
(in<br>
> > which case the module needs to enter some kind of error or inactive
state)?<br>
> ><br>
> > Glyn<br>
> ><br>
> > *"Richard S. Hall" <heavy@UNGOVERNED.ORG>* wrote
on 22/06/2007 01:21:48 PM:<br>
> ><br>
> > > I think your suggestion is reasonable.<br>
> > ><br>
> > > -> richard<br>
> > ><br>
> > > Stanley M. Ho wrote:<br>
> > > > Hi JSR 277 experts,<br>
> > > ><br>
> > > > Since we have been discussing some issues around
the module instances'<br>
> > > > lifetime lately, I think it's probably a good
time to bring up a<br>
> > related<br>
> > > > topic for discussion.<br>
> > > ><br>
> > > > As I reviewed the feedbacks from the EDR comments,
from our previous<br>
> > > > discussions, as well as from my discussions with
the teams in SE<br>
> > and EE,<br>
> > > > there were a few suggestions related to the module
instances'lifetime:<br>
> > > ><br>
> > > > 1. The module system shall provide a way to monitor
various events,<br>
> > e.g.<br>
> > > > module initialized, module released, etc.<br>
> > > > 2. The module system shall allow a module to
have activator code. The<br>
> > > > activator code would be executed right before
the module is fully<br>
> > > > initialized and when the instance is released.<br>
> > > > 3. A module shall have a way to be stopped.<br>
> > > ><br>
> > > > Having these suggestions don't mean we have to
do all of them, and I<br>
> > > > would like to get your inputs.<br>
> > > ><br>
> > > ><br>
> > > > From my perspective, having a way to monitor
module system's events<br>
> > > > (i.e. #1) seems very reasonable and useful, especially
the use<br>
> > cases are<br>
> > > > very common. In fact, many teams in SE have expressed
the needs in<br>
> > > > monitoring the module system's events in their
class libraries in some<br>
> > > > degrees, so these libraries would react and behave
appropriately. There<br>
> > > > are also other class libraries sitting on top
of the JRE that have<br>
> > > > similar needs.<br>
> > > ><br>
> > > > For #2, this is a use case I gathered from EE,
and this would be used<br>
> > > > mainly for registering and unregistering services
when a module has<br>
> > been<br>
> > > > initialized or is released. Not that I think
this is unimportant, but I<br>
> > > > am not yet convinced this is something we need
to support directly at<br>
> > > > the module system level. For instance, if the
module system<br>
> > notification<br>
> > > > mechanism (i.e. #1) is available, it should be
possible for the EE<br>
> > > > server (or other apps that require similar functionality)
to build a<br>
> > > > simple activator layer on top of the module system.<br>
> > > ><br>
> > > > For #3, the use case is that some EE servers
might want to have the<br>
> > > > ability to "stop" a module by disabling
the module's classloader when<br>
> > > > the module instance is released. In general,
disabling a classloader is<br>
> > > > an uncommon and dangerous operation to perform,
and it also<br>
> > violates the<br>
> > > > current classloading spec. While I agreed we
should make this use case<br>
> > > > possible, I don't think this is something we
want to push into the<br>
> > > > module system.; I believe there are alternatives
we could consider to<br>
> > > > achieve the same result. For example, suppose
there are APIs available<br>
> > > > to disable a classloader (might come from the
classloading project) and<br>
> > > > the module system notification mechanism (i.e.
#1) is available, it<br>
> > > > should be possible for the EE servers to hook
into the notification<br>
> > > > mechanism, and disable the specific classloader
it wants when a module<br>
> > > > instance is released from the module system.<br>
> > > ><br>
> > > ><br>
> > > > To keep things simple, I suggest we should support
#1, and I hope this<br>
> > > > should be sufficient to enable other applications
(e.g. EE servers) to<br>
> > > > support #2 and #3. I would like to hear what
your thoughts are.<br>
> > > ><br>
> > > > - Stanley<br>
> ><br>
> ><br>
> ><br>
> > ------------------------------------------------------------------------<br>
> ><br>
> > /<br>
> > /<br>
> ><br>
> > /Unless stated otherwise above:<br>
> > IBM United Kingdom Limited - Registered in England and Wales
with number<br>
> > 741598.<br>
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU/<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
</font></tt><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>