Thanks to @ibacher, @suruchi, @ruhanga and @mseaton, Initializer now supports an /ocl config folder. I’m finding this very useful, because (1) it means I don’t have to keep re-subscribing to collections if our demo server goes down, (2) it means our 3.x RefApp is ready-to-go with demo concept collections (see here), and (3) offline sites can be set up with concepts originally created in OCL, without needing an internet connection.
Is Iniz currently able to read files within an OpenMRS module or do we always have to deploy files into a folder on the file system rather than in the resources folder of an api sub-module
By design, Initializer only reads files from the configuration directory in the OpenMRS Application Directory. Bundling metadata into modules is, of course, a way to get a module quickly working, but it reduces the reusability of the module itself. The discussions around “packaging” represent the sort of evolving notion of how we can bundle up both metadata with executable code. Ideally, packaging and a reliance on more generic methods for concept identification (like using concept maps in place of concept UUIDs) will help us get to a better state.
@ibacher In our case packaging is centralized as the concepts are packaged once for distribution within a WAR file so sites do not have to create and manage a configuration folder or file
You could always add functionality to your module activator to expand whatever resources it wants loaded to the configuration folder in the app directory. Iniz doesn’t do anything until it’s module activator is called which is usually quite late in the initialization process, since Iniz depends on most other modules.
At PIH we control the invocation of Initializer loading programmatically, to ensure that it is done at a specific time in the module loading process, that certain domains are loaded in certain ways, with certain validation rules, and that some custom metadata loading can be interspersed in the process. So as @ibacher points out @ssmusoke , you can use Iniz and still retain the control you want from within your own modules and distribution startup process.
Then, you can do whatever you need to do in code to move CSVs from your module resources into the configuration directory and then invoke initializer loading programmatically like we do here:
@mksd@mksrom How can I set Iniz not to start as I already have a runtime properties file created and cannot hand-edit it? Is there another option like a global property?
As an alternative or complement to runtime properties, any property may also be specified as a system property. The order of precedence if both are used on the same system is that any property set via a system property will override any value set as a runtime property. If a system property is specified with an empty value, this will also override the runtime property with this empty value.
Runtime properties can be specified at server startup with -DpropertyName=propertyValue. They can also be specified in SDK environments by adding these properties to one’s openmrs-server.properties file
@ssmusoke, I’d think that hooking into one of your custom module’s activation lifecycle might suffice for you, adding something along the following lines - maybe in it’s willStart() hook.
