Skip to content

Spring refactor - #146

Open
Albireo-B wants to merge 6 commits into
virtual-imaging-platform:developfrom
Albireo-B:feature/refactor-spring
Open

Spring refactor#146
Albireo-B wants to merge 6 commits into
virtual-imaging-platform:developfrom
Albireo-B:feature/refactor-spring

Conversation

@Albireo-B

Copy link
Copy Markdown

No description provided.

@Albireo-B
Albireo-B force-pushed the feature/refactor-spring branch from ac9023a to d4f28d3 Compare June 11, 2026 07:40
@axlbonnet

Copy link
Copy Markdown
Contributor

It's excellent, exactly what I had in mind, use Spring to :

  • get rid of the current plugin library
  • improve the threads scheduling in many places
  • improve configuration
  • improve a little the database management. There was already Hibernate so it does not change much, although transaction is clearer now.

I'll do a more complete review but here come some thoughts:

  • Moteur-Lite will start Gasw, I thing that Gasw shoud provide some sort of static class to do that. (maybe I missed it)
  • make sure spring destroy (and closes all the threads)
  • about configuration, I'm not sure where the config file is meant to be.
  • we can get rid of the old script management system (for the abandoned Moteur2, that used velocity)
  • we can migrate the h2 plugin in here, to simplify some stuff
  • maybe migrate the listener plugins here also later
  • some automatic Tests to ensure spring config, screduling, configuration files, transaction, proper destruction of threads...

Guillaume V. added 2 commits June 15, 2026 10:51
…es and classes + add GaswLauncher static access class and fix notification system
@Albireo-B
Albireo-B marked this pull request as ready for review July 3, 2026 08:23
@Albireo-B

Copy link
Copy Markdown
Author

provided

  • I added a static GaswLauncher class that do the bridge between Spring and the workflow engine (see vip-workflow-engine PR)

  • Made sure terminate (soft or hard) is propagated to sub-plugins and thread-handling classes.

  • About Configuration, each project own a *.properties file (ex : local-plugin.properties, gasw.properties, etc...) which holds the old vars. I added in GaswLauncher a function that loads custom *.properties files. The behavior is :
    - Gasw is launched (via launcher) : it looks for all *.properties files in user.home env variable (set in moteur-server -> in docker it creates a .gasw folder)
    - Uses those files values in priority (ex : plugin.local.thread=1 in .gasw/local-plugin.properties overrides the default)
    - Completes the rest of the vars with the default ones (the ones in project local-plugin.properties)
    This way we can still have values override easily (replaces the .settings files)
    BUT I don't really know yet the behavior of user.home folder creation in ansible or local vip. If the settings are always put in this folder then it's fine, else it needs to be changed.

  • I didn't migrate the H2 and listener plugins inside gasw yet, I find it weird that some plugins are in Gasw and some not, and separating responsabilities seems fine. But maybe it's simpler to merge all the plugins into gasw, so i don't really know.

  • Added some tests in all projects, tried to test the useful stuff but not sure I covered everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants