Update architecture for internal API, remove vip-api.conf #594
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Decouple SpringCoreConfig from vip-api: - Add an explicit root context in web.xml, bound to SpringCoreConfig - Bind /rest API servlet to SpringWebConfig instead of SpringCoreConfig - Update components scanning to have all RestController beans in SpringWebConfig instead of SpringCoreConfig This will allow to add new servlets for independent new APIs. Decoupling is not complete yet, as securityFilterChain is still in vip-api.
Move securityFilterChain bean and its dependencies from vip-api to vip-core.
- Move securityFilterChain (vip.api.security package) from vip.api to vip.core.server - In vip-api, rename SpringWebConfig.java SpringRestApiConfig.java - In vip-core, add a stub handler for a prototype internal api, currently mapped to /core WIP: everything seems to work, but unit tests in vip-core are broken.
- Update components scanning so that it is symmetrical for /rest and /core. Exclude @EnableWebMvc in addition to @RestController to avoid recursive scan. - Add commented out logging for components scanning. - Make the root context (SpringCoreConfig) a WebMvc context, as required by having Spring Security at that level. - Fix all tests by: . adjusting the context dependencies: this seems clean enough . making vip-api.conf optional: this is quick&dirty, should be a proper mock instead
- Rename /core endpoint to /internal - Update vip-api.conf handling so that required properties are verified when the file is present, add some context on vip-api.conf optional handling. This is still "not for production", but cleaner.
vip-core/src/test/resources/vip-api.conf was added in 26c6efe (back when tests were broken), but is not actually needed.
Conflicts fixed
- CarminProperties keys are now exposed through the Server bean instead of Environment. - Mandatory keys are unchanged. - Settings are mocked in either vip-core or vip-api modules depending on their usage. Everything works, but some implementation details are left todo: define proper getters for API properties (instead of the temporary getEnvProperty helpers), and see if cors.authorized-domains can be moved from vip-core to vip-api.
- Rename CoreTestController to SessionController and add basic JSON test content - Create an ApplicationController stub in vip-applications - Ajust components scanning for the internal API controllers - Rename SpringCoreApiConfig to SpringInternalApiConfig - Rename ApiSecurityConfig to RestApiSecurityConfig
- Update scanning comments - Remove vipConfigFolder in BaseSpringIT, now useless with mocks
axlbonnet
reviewed
Oct 2, 2025
Contributor
axlbonnet
left a comment
axlbonnet
left a comment
There was a problem hiding this comment.
Thanks for the spring mvc refactoring !
Just a remark about what seem to be wrong constants names.
vip-api/src/main/java/fr/insalyon/creatis/vip/api/business/DataApiBusiness.java
Outdated
Show resolved
Hide resolved
vip-api/src/main/java/fr/insalyon/creatis/vip/api/business/DataApiBusiness.java
Outdated
Show resolved
Hide resolved
vip-api/src/main/java/fr/insalyon/creatis/vip/api/business/DataApiBusiness.java
Outdated
Show resolved
Hide resolved
Wrong in three places, mixed up with getCarminApiDefaultMimeType()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch is an internal refactoring, which sets the ground for future work on a new internal API for a future JS frontend.
It does the following :
/internalAPI endpoint, containing only stubs for nowvip-api.conf, now merged intovip.conf/restAPI and GWT UI should be strictly unchangedDetails :
web.xml:vip-core/SpringCoreConfig/restAPI context invip-api/SpringRestApiConfig/internalAPI context invip-core/SpringInternalApiConfigGET /internal/sessionandGET /internal/applications. For now, these new endpoints return only constant test data, and do not have authentication support yet. This illustrates that components scanning and modules separation behave as intended.vip.api.securitytovip.core.server.security(as Spring mandates that the securityFilterChain is in the root context) :pom.xmldependencies for Spring Security and Hibernate validator fromvip-apitovip-corevip-api.confintovip.conf: all global settings are now in a singlevip.conffile, and accessed trough theServerbean (instead ofEnvironment). Mandatory keys are unchanged.test/resources/.../vip-api.conffiles, and updateServermocking accordingly in tests