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. 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. If the use case is that the module's activator should be called by the container when the module is fully initialized or is released, the notification mechanism should be sufficient for this purpose. If the use case is that a module instance should be released if its module's activator fails to start, the notification mechanism should still be sufficient, assuming the container will call ModuleSystem.releaseModule() after the container has received the module initialized notification but fails to start the activator. (Yes, there are side effects with releaseModule() as we discussed before, but it's a problem the container can probably deal with.) Is there any other use case that you think is important to consider but not allowed by this notification mechanism? - Stanley
