(Sorry, somehow this message got marked read and I only just now saw it.)
Comments inline.
Stanley M. Ho wrote:
Bryan Atsatt wrote:
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 mechanism I have in mind can be registered only by code that have
the appropriate security permissions, and untrusted code in the sandbox
won't be able to listen to the notification.
I am still a bit puzzled by why the module's state needs to be coupled
directly to the result from the module's activator because this looks to
me more like a solution to a problem than a requirement. For that model
to work, I think there are couple underlying assumptions, but they might
not be valid in our case:
1. If a module's activator is executed before the module is fully
initialized, it can safely register something into some service lookup
mechanism in the system.
2. The service lookup mechanism will make sure the registered thing from
that module is not usable by other modules unless that module becomes
fully initialized.
3. If the module's activator fails to execute when the module is being
initialized, the module system knows how to work with the service lookup
mechanism to undo all the unregisterations automatically and correctly.
So do you expect that java.util.ServiceLoader will do this?
In this case, the module system probably needs to be highly integrated
with the service lookup mechanism, and that mechanism should be the only
one used by all the modules' activators. However, in practice, multiple
service lookup mechanisms exist and can be used in the Java platform,
and I don't think we should expect the module system will know how to
work with these arbitrary mechanisms to provide the suggested module's
state semantic in conjunction with the module's activator. Also, from
our previous discussions, I think our consensus is to avoid pushing the
service mechanism down to the module layer if possible.
I agree that we shouldn't try to push a *service* mechanism into the
module layer.
But a generic *activator* certainly seems appropriate. Some modules will
need to perform initialization prior to use (e.g. process a config file,
check some environmental constraints, populate a JNDI context, etc,
etc). Successful initialization for such a module is then a
pre-condition for use, and any failure should be treated exactly as
seriously as a resolution failure.
Yes, this *could* be done using the notification mechanism, but that
strikes me as a rather hackish approach. This use case is not limited to
"container" environments, so, IMO, should be made part of the spec.
And it seems like a rather small addition:
1. A simple interface that the module can implement, e.g.:
interface ModuleActivator {
public void start(Module module) throws Exception;
public void release(Module module) throws Exception;
}
2. An annotation to declare the activator impl name.
3. Module system instantiates and invokes activator (at end of
prep/validation or a new step). An exception here would put the module
into ERROR state.
Exactly what such an activator does is mostly irrelevant, though it
clearly cannot consume the thread; the usual precautions here should
suffice.
// Bryan
