I would be interested in us making any changes we feel are appropriate to core to better support the goals laid out in this thread: Asynchronous message queuing, retries, and error handling . Basically I think this involves adding Event firing and listener registration to core such that these events are guaranteed delivery and transactional (listeners can choose to participate synchronously in the transaction or choose to run asynchronously outside of the transaction), and such that no module ever needs to implement a Hibernate Interceptor but can simply rely upon the core Event publishing API with 100% confidence.
While this can also be done in an improved event module, doing this in core allows us to decide to fire events at all sorts of interesting places throughout the core codebase that a module may be interested in plugging into, and allow us to get rid of AOP and other multiple Hibernate Interceptors altogether.
I would also be interested in improving the module loading lifecycle such that modules can have more fine-grained control over when certain functionality might be executed, whether in relation to core or in relation to other modules. A few specific examples:
- My top-level distribution module depends on Initializer, but wants to invoke the Initializer API directly to have more control over when and how it loads the configuration, rather than have this happen during the Initializer activator’s started method. Currently this can only be controlled at the distribution level by setting certain runtime or system properties. It cannot be coded into the top-level module.
- My implementation has a bunch of data that was created in an older version of OpenMRS and now fails validation rules. I want to write some migration scripts and deploy them in my module and have them execute before OpenMRS runs any liquibase changesets. Currently there is no way for a module to inject behavior into this phase of OpenMRS startup.