I've recently been working with the Document Generation module and noticed a limitation in how its configuration is handled.
In the Document Generation module, several Java actions rely directly on Mendix constants, such as Constants.getServiceEndpoint(), which is loaded into ConfigurationManager as a static final field. This design prevents changing important values like the service endpoint without restarting the application. Although the module includes a Configuration singleton with fields such as ApplicationUrl, this entity is not used by the implementation for endpoint selection. As a result, runtime configuration updates are impossible even though the domain model suggests they should be supported. I believe the constant should act only as a default value, and the Java actions should read their configuration from the singleton instead. This would allow programmatic updates and dynamic configuration changes without downtime. It would also make the module’s behavior consistent with how its configuration entity is presented to developers.
yes Frederik, I believe our org built a seperate private component for Document Generation and we are using the same.
Hi Ajay, So, you adjusted the Java Implementations accordingly? Because changing the config object (which comes with the module), these values won't change the behaviour of JA_GenerateDocument.java, because the ConfigurationManager class uses the constant.
In our app, we created a system configuratons entity and created a page for Admin to modify these configurations.
And with this approach, having a different configurations for each env and those values can be changed without a system restart.
I've seen the same approach for some other recent modules to move towards Constants for environment related configuration data.
While this is one viable option for certain use cases it shouldn't be the only way for doing that.