Module system notification mechanism

[Bryan Atsatt]

(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