How auto-configuration works
The Spring Boot Starter uses@ConditionalOnMissingBean annotations on all auto-configured beans. This means your custom beans take precedence over the defaults. If you define a bean of the same type, the auto-configuration skips creating its version.
How to override a bean
Define a bean of the same type in your configuration class:IncrementalUniqueIdGenerator.
Common customization scenarios
Custom ID generator
The default ID generator uses an incremental counter starting from the epoch second. To use a different strategy:Custom security manager
To implement custom authorization logic, provide your ownIDatabaseSimulationsSecurityManager:
custom in your configuration:
Custom workflow
To modify how simulations are created, executed, or deleted:Custom distributed database service
When running in distributed mode, you can provide a custom implementation:Custom SessionFactory
To customize the HibernateSessionFactory beyond what persistence properties provide (such as adding interceptors or event listeners):
destroyMethod = "close" attribute ensures the SessionFactory closes properly when the application shuts down. When you override the SessionFactory, the default ISimulationPersistenceManager automatically uses your custom instance.
Bean dependencies
When customizing beans, be aware of their dependencies. The auto-configuration wires beans together in this order:DatabaseSimulationEngineandIUniqueIdGenerator(no dependencies)SessionFactory(requiresIWhatIfPersistenceProperties)ISimulationPersistenceManager(requiresSessionFactory)IDatabaseSimulationsSecurityManager(may require persistence manager)IDatabaseSimulationsWorkflow(requires engine, persistence manager, security manager, database service, ID generator)DatabaseSimulationsRestService(requires workflow, persistence manager, database service)