<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 25/06/2007 06:00:12 PM:<br>
<br>
> It seems simple enough to put the module in a failed state if a<br>
> module-init event handler throws an exception. Is this not sufficient?</font></tt>
<br>
<br><tt><font size=2>No, I don't think so.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2><br>
> <br>
> The lazy init feature sounds like a nice optimization, but doesn't<br>
> strike me as a must-have. Have you seen use-cases that require it?
Are<br>
> they init order issues?</font></tt>
<br>
<br><tt><font size=2>I agree it's not a must have as JSR 291 handles that.</font></tt>
<br><tt><font size=2><br>
> <br>
> <br>
> (I am sensitive to your meta point here, but... If 277 is going to<br>
> exist, there are some rather obvious, desirable features which it
will<br>
> need, just as OSGi needed them. I _don't_ like the fact that we are<br>
> re-inventing rather than re-using OSGi, but that is how it has played<br>
> out, despite all protestations. As long as we can still attain the
goal<br>
> of meaningful interoperation, it seems irresponsible to leave out<br>
> features like this. And yes, we must nail down the interoperation
model<br>
> before we go much/any farther.)</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Glyn</font></tt>
<br><tt><font size=2><br>
> <br>
> Glyn Normington wrote:<br>
> ><br>
> > Yes, but my point was that separating lifecycle out in that way
would<br>
> > make it harder to enforce constraints like "if a module's
state is<br>
> > initialised, the module's activator completed successfully".<br>
> ><br>
> > JSR 291 solved this problem with additional module states and
error<br>
> > handling. It also supports lazy module initialisation triggered
by the<br>
> > first class load from a module. How much of this should JSR 277
re-invent?<br>
> ><br>
> > Glyn<br>
> ><br>
> > *Bryan Atsatt <bryan.atsatt@ORACLE.COM>* 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<br>
> > 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<br>
> > state)?<br>
> > > ><br>
> > > > Glyn<br>
> > > ><br>
> > > > *"Richard S. Hall" <heavy@UNGOVERNED.ORG>*
wrote on 22/06/2007<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > instances'lifetime:<br>
> > > > > ><br>
> > > > > > 1. The module system shall provide
a way to monitor various<br>
> > events,<br>
> > > > e.g.<br>
> > > > > > module initialized, module released,
etc.<br>
> > > > > > 2. The module system shall allow
a module to have activator<br>
> > 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,<br>
> > and I<br>
> > > > > > would like to get your inputs.<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > From my perspective, having a
way to monitor module system's<br>
> > 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<br>
> > in some<br>
> > > > > > degrees, so these libraries would
react and behave<br>
> > appropriately. There<br>
> > > > > > are also other class libraries
sitting on top of the JREthat have<br>
> > > > > > similar needs.<br>
> > > > > ><br>
> > > > > > For #2, this is a use case I
gathered from EE, and this would<br>
> > be used<br>
> > > > > > mainly for registering and unregistering
services when a<br>
> > module has<br>
> > > > been<br>
> > > > > > initialized or is released. Not
that I think this is<br>
> > unimportant, but I<br>
> > > > > > am not yet convinced this is
something we need to support<br>
> > 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<br>
> > 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<br>
> > have the<br>
> > > > > > ability to "stop" a
module by disabling the module's<br>
> > classloader when<br>
> > > > > > the module instance is released.
In general, disabling a<br>
> > 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<br>
> > 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<br>
> > consider to<br>
> > > > > > achieve the same result. For
example, suppose there are APIs<br>
> > available<br>
> > > > > > to disable a classloader (might
come from the classloading<br>
> > project) and<br>
> > > > > > the module system notification
mechanism (i.e. #1) is<br>
> > available, it<br>
> > > > > > should be possible for the EE
servers to hook into the<br>
> > notification<br>
> > > > > > mechanism, and disable the specific
classloader it wants when<br>
> > 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<br>
> > hope this<br>
> > > > > > should be sufficient to enable
other applications (e.g. EE<br>
> > 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>
> > > ><br>
> > > > /Unless stated otherwise above:<br>
> > > > IBM United Kingdom Limited - Registered in England
and Wales with<br>
> > number<br>
> > > > 741598.<br>
> > > > Registered office: PO Box 41, North Harbour,
Portsmouth, Hampshire<br>
> > PO6 3AU/<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><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>