Migrate to 6.0.0
This is a major version that upgrades the underlying stack from Atoti Server 6.0.9 on Java 17 to Atoti Server 6.1.19 on Java 21. The scope of work depends on how much the default source tree has been modified.Choose your migration path
When in doubt, start by producing a patch against a pristine 5.1.3 checkout (Step 0 of Path C). If the patch touches only one file, follow Path B. If the patch is empty, follow Path A.
Headline changes
Every migration path accepts these changes. Paths B and C require additional handling.- Java 21: Java 17 is no longer supported. The Maven build enforces
requireJavaVersion21. - Atoti Server 6.1.19: Upgraded from ActivePivot 6.0.9. All
com.qfs.*andcom.quartetfs.*package roots move tocom.activeviam.{activepivot,tech,database,web}.*. - Spring Boot 3 / Jakarta EE 10:
javax.*replaced byjakarta.*across the board. - Spring Security 6:
WebSecurityConfigurerAdapterremoved; replaced bySecurityFilterChainbeans. - OpenTelemetry 1.43.0: Spring Cloud Sleuth and Zipkin Brave removed.
- Module restructuring: 5 modules become 8.
cvarc-applicationis the new executable;cvarc-starterbecomes an auto-config library. See Module rename. - What-If 2.1.6-AS6.0 → 5.0.0-AS6.1: Hibernate-based persistence, JWT authentication, new file-upload distributed mode. See What-If 2.1.6-AS6.0 → 5.0.0-AS6.1.
- Atoti Server 6.1.19: New Spring Boot starters replace hand-wired configuration. See Atoti Server 6.1.19 starters.
- Atoti Limits 4.2.1: GroupId and artifact ID changed; disabled by default. See Atoti Limits 4.2.1.
- Common Accelerator Library 2.1.15-AS6.1.
AtotiAuthToken → SharedSecretAuthToken), Hibernate group ID (org.hibernate → org.hibernate.orm, only relevant for module POMs that pull Hibernate directly), and CVARCEnvConstants constant suffix renames (_SYSPROP/_SYNSPROP/_PROP → _PROPERTY).
Path A — no customization
This path is for users who cloned the source, built it, and run the resulting jar or Docker image without any local edits. The total work is installing a new JDK, swapping the source tree, rebuilding, and updating the launch command.Step 1: install JDK 21
5.1.3 enforced JDK 17. 6.0.0 enforces JDK 21 viarequireJavaVersion in the root POM. The Maven build fails immediately on the wrong JDK.
Step 2: replace the source tree
Swap the 5.1.3 working copy for the 6.0.0 source. The module list changes as follows:
With git, this is a single checkout of the 6.0.0 tree over the 5.1.3 tree. There are no merge decisions for an as-is user — every file at the same logical path moves together.
See Complete change inventory for the full scope of what this swap brings in.
Step 3: rebuild
Run from the project root:cvarc-starter/target/cvarc-starter-5.1.3-exec.jar. The 5.1.3 cvarc-starter module remains in 6.0.0 but no longer produces an exec jar — its POM has no spring-boot-maven-plugin repackage execution.
Step 4a: update your launch command — direct jar
Old (5.1.3):- Jar path and name change to
cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar. chunkAllocatorClass=…MmapDirectChunkAllocator→chunkAllocatorKey=mmap.--add-opens=java.base/java.util=ALL-UNNAMEDis a new required flag.--content-service.db.url=…is no longer needed — now configured inapplication.yml.--csv.topic.pathis new, pointing the Data Load Controller at the CSV samples directory.- Spring Boot context path moves from
/cvarc-starterto/cvarc-application. Update any client or proxy pointing at the old path.
Step 4b: update your launch command — Docker
The Dockerfile has moved fromcvarc-starter/Dockerfile to cvarc-application/Dockerfile. The new Dockerfile already has the updated chunk-allocator flag, so no launch-command changes are needed beyond using the new image.
Before building, pre-copy the files the Dockerfile expects:
docker build cvarc-application/ without the pre-copy step will fail. The same pre-copy pattern existed for 5.1.3, but the source paths are different.
Step 5: update external file references
The repo-rootbookmarks/ directory contents have not changed between 5.1.3 and 6.0.0. data-samples/ moves from cvarc-starter/data-samples/ to cvarc-application/data-samples/, with unchanged contents. If --contentServer.factory-reset.folder-name, --csv.topic.path, or any CI/Docker mount points at one of these directories, update the path or symlink. See Path C step 6 for the full list of fixture relocations, including the removed cvarc-isda-tests/content_service.mv.db and the property-files move.
Path B — light customization (single @Configuration)
This path is for users who maintain one isolated@Configuration class wired into the application via a single @Import(MyCustomConfig.class) line on ApplicationConfig. Everything else is stock.
Follow this path only if all of these are true:
- The custom file is a single
@Configurationclass with@Beanmethods, wired by exactly one@Import(...)line on 5.1.3’sApplicationConfig. - It does not extend, subclass, or override any of the configs deleted from cvarc-common or cvarc-starter — including all
*Tracing*(BraveTracingConfig,TracingConfig,TracingRestServiceConfig),*Monitoring*andActiveMonitor*(JmxMonitoringConfig,MonitoringRestServicesConfig,ApplicationMonitoringConfig,ActiveMonitorSupportConfig),*CsvSourceConfig,DataLoadControllerConfig,DatastoreConfig,LimitsIntegration,JwtAuthenticationConfigurer,CorsConfig,WhatIfConfig(cvarc-common),WhatIfRestServices,CVARCWhatIfSecurityManager,DoctorPivotConfig,CVAI18nConfig, andI18nConfig. See Step 5 for the full list with replacement guidance. - It does not customize
util.ReferenceLevelUtils(deleted with no upstream replacement). OtherReferenceLevel*types moved upstream tocom.activeviam.accelerator.common.{context,postprocessor}.*— Path A still applies if you’re comfortable doing the import rename. - JDK 21 runtime is acceptable.
Step 1: check out the 6.0.0 tree — do not forward-port
Check out 6.0.0 cleanly. Do not forward-port the 5.1.3 working copy. Starting from the clean 6.0.0 tree is cheaper because:- The parent POM jumps from
common-parent-pom 1.2.0to2.5.0, which retunes the entire dependency graph (Tomcat 9 → 11, slf4j 1.7 → 2.0, logback 1.2 → 1.5, Jakarta servlet API). - The module list reshapes:
cvarc-commonsplits intocvarc-common-lib+cvarc-common-config;cvarc-ba-activepivot→cvarc-ba-config;cvarc-sa-activepivot→cvarc-sa-config;cvarc-starteris demoted from executable to auto-config library; the newcvarc-applicationmodule owns the executable plus the mainApplicationConfig. Replaying these renames over a 5.1.3 checkout is more work than dropping one file into the new tree. - The
@Importgraph is now centered oncvarc-application/.../cfg/ApplicationConfig.javawith about 25 entries (down from ~50 in 5.1.3), because the deleted configs are now provided transitively by the Atoti Spring Boot starters. The entry point moved fromCVAWebApplication(@Configuration @EnableAutoConfiguration @EnableWebMvc, hand-rolling severalDispatcherServlet/Filter/ServletContextInitializerbeans) toCVARCApplication(@SpringBootApplication @EnableWebMvc; those beans are gone).
Step 2: move the custom file
The new
ApplicationConfig lives at cvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/ApplicationConfig.java. Placing the custom file in the same module avoids cross-module dependency edits. Keep the original Java package — Spring @Import is package-agnostic.
Step 3: re-wire the import
Opencvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/ApplicationConfig.java and add the class to the existing @Import list:
import <your-package>.MyCustomConfig; at the top of the file.
Do not add it to CVARCApplication — CVARCApplication only @Imports ApplicationConfig, exactly as 5.1.3’s CVAWebApplication only imported ApplicationConfig.
Step 4: fix package and API changes
Runmvn -pl cvarc-application compile. The compiler errors identify exactly which symbols to rename. Drive edits from those errors — do not pre-emptively rewrite anything that still resolves.
The renames most likely to appear, based on the imports of the new ApplicationConfig:
For any
com.qfs.* or com.quartetfs.* types not listed above, search them in the 6.0.0 tree (grep -r 'class TypeName' .) before guessing. The Atoti Server 6.1.19 reorganization moved most types from com.qfs/com.quartetfs to com.activeviam.{tech,activepivot,database,web}.*.
Step 5: remove or replace references to deleted configs
Remove any references to the following, if they appear in the custom file. For replacement details (where the behavior now lives, what to redesign against), see Path C bucket D.- Tracing —
BraveTracingConfig,TracingConfig,TracingRestServiceConfig,brave.Tracing. - JMX / monitoring —
JmxMonitoringConfig,MonitoringRestServicesConfig,ApplicationMonitoringConfig. - ActiveMonitor —
ActiveMonitorSupportConfig, the ActiveMonitor stack (activemonitor-activepivot-impl,repository-activepivot,apm), andactivemonitor-support.properties. - CSV sources —
Ba{Aws,Azure,Google,}CsvSourceConfig,Sa{Aws,Azure,Google,}CsvSourceConfig,Shared{Aws,Azure,Google,}CsvSourceConfig,Crif{,Azure}CsvSourceConfig,CommonCloudSourceConfig, and theACsvSourceConfigfamily. - Data load —
DataLoadControllerConfig,InitialDataLoadConfig(the first is gone; the second is reshaped undercvarc-starter/.../cfg/impl/dlc/). - Security —
JwtAuthenticationConfigurerandCorsConfigare deleted outright; CORS is now config-driven. All other security classes have relocated fromcvarc-starter/.../security/tocvarc-application/.../security/with the same class names. - What-If —
WhatIfConfig(cvarc-common copy),WhatIfRestServices. Controllers (StressedSensitivityWhatIfRestController,ParameterSetRestServiceController,TradeRescaleRestServiceController) relocated tocvarc-application/.../whatif/with the same names. - Limits —
LimitsIntegration. The newlimits-auto-config-61starter is auto-wired but disabled by default; setlimits.autoconfiguration.enabled=trueif the customization relied on it. - DoctorPivot —
DoctorPivotConfig,doctorpivot-api,doctorpivot-web-app. - i18n —
CVAI18nConfig,I18nConfig,CVARCWhatIfSecurityManager. - ReferenceLevel context-value chain —
IReferenceLevelContextVal,ReferenceLevelContextVal,ReferenceLevelVisualTotalsModeContextVal,ReferenceLevelVisualTotalsModeTranslator,postprocessor.ReferenceLevelLocationShift. Moved upstream tocom.activeviam.accelerator.common.{context,postprocessor}.*— see Bucket C for the import rename.util.ReferenceLevelUtilswas deleted with no replacement; see Bucket D.
Step 6: update the POM (only if the custom file lives in a sibling module)
If the custom file was moved intocvarc-application in step 2, the POM does not need to change. Skip this section.
If the customization instead lives in a sibling module:
- Inherit from
<artifactId>cvarc</artifactId><version>6.0.0-SNAPSHOT</version>parent (no version on dependencies; let the parent BOM manage them). - Add
cvarc-common-lib,cvarc-common-config, andcvarc-starteras compile dependencies if the customization needs constants or configs from them. - Remove these old artifacts if the module POM declares them:
com.activeviam.io:data-connectors-{csv,jdbc,aws,azure,gcp},com.activeviam.activemonitor:*,com.activeviam.apm:apm,com.activeviam.apps:whatif,com.activeviam.apps:cvarc-{ba,sa}-core,org.springframework.cloud:spring-cloud-{starter-sleuth,sleuth-zipkin},io.zipkin.brave:brave-instrumentation-spring-webmvc,com.activeviam.apps:doctorpivot-{api,web-app},org.junit:junit-bom,com.activeviam.activepivot:activepivot-test. - Switch any
javax.servlet:javax.servlet-apitojakarta.servlet:jakarta.servlet-api(scopeprovided).
Step 7: update the Dockerfile (only if a custom Dockerfile is maintained)
The shipped Dockerfile moves fromcvarc-starter/Dockerfile to cvarc-application/Dockerfile. For a forked Dockerfile, apply the JVM flag changes from Java 21 upgrade and the full Dockerfile diff from Docker configuration. Update any reverse proxy or client referencing the old /cvarc-starter context path; it is now /cvarc-application.
Step 8: build and smoke-test
Path C — heavy customization (multi-module edits)
This path is for users who have spent significant time editing 5.1.3 source files in place — multiple modified@Configuration classes across cvarc-common, cvarc-starter, cvarc-sa-activepivot, cvarc-ba-activepivot, possibly inline tweaks to listeners, publishers, post-processors, and security wiring.
The critical risk for heavy customizers is misreading the removed-class list. About half of the classes that appear “deleted” were relocated to upstream binary dependencies and still appear in 6.0.0’s @Import block. Treating them as deletions and redesigning wastes weeks. Treating them as overrideable bean seams using @ConditionalOnMissingBean takes hours. The first job is to bucket every customized file before touching code.
Assume JDK 21, Jakarta servlet, parent-POM bumps, Brave → OpenTelemetry, and the cvarc-starter → cvarc-application split as known background from Paths A and B.
Step 0: capture customizations as a patch set
Before opening 6.0.0, run this against a pristine 5.1.3 checkout:customizations.patch per file — one hunk per modified Java class. This is the input to the bucket triage in step 2. Without it, hunks will be misclassified and the same file merged twice.
Step 1: start from a clean 6.0.0 checkout
Do not rebase 5.1.3 onto 6.0.0. Module renames, thecom.qfs.*/com.quartetfs.* → com.activeviam.* mass rename, and the parent-POM 1.2.0 → 2.5.0 jump make a backward merge strictly more expensive than a clean-tree replay.
Step 2: bucket every customized file
For each entry in the patch set, classify into one of four buckets:
The volume distribution from this codebase is roughly A > B > C > D, but D is the bucket that absorbs the most calendar time per file.
Bucket A — same package path, possibly new module
Apply hunks unchanged (package declarations are identical). Module homes:Bucket B — same code, new home
Bucket C — gone from source; override the upstream bean
These classes are referenced by 6.0.0’sApplicationConfig @Import list but have no source file in the tree. They live in upstream artifacts. Do not vendor them back.
The new
ApplicationConfig.startManager carries @ConditionalOnMissingBean(name = "startManager") and InitialDataLoadConfig carries the same annotation. The framework explicitly invites bean replacement via this mechanism.
Bucket D — redesign against the new API
These are the same subsystems flagged as a removal checklist in Path B step 5; the table below adds the redesign target for each.Step 3: run the global find-and-replace for cross-cutting renames
Run these after moving files and before attempting to compile. The Atoti Server 6.1.19 reorganization flips practically every framework import.
Once done, run:
Step 4: re-wire @Import and the bootstrap class
The new cvarc-application/.../application/cfg/ApplicationConfig.java carries 25 imports versus 5.1.3’s ~50. The deletions are replaced by starter auto-config. Add custom @Configuration classes to that block — do not add them to CVARCApplication, which only @Imports ApplicationConfig.
The new CVARCApplication is @SpringBootApplication @EnableWebMvc @Import({ApplicationConfig.class}). The 5.1.3 CVAWebApplication carried hand-rolled DispatcherServletRegistrationBean, FilterRegistrationBean<ContextValueFilter>, and ServletContextInitializer beans — all deleted. Spring Boot’s auto-wiring covers the equivalent. Port the intent to a Spring Boot property or starter customizer; do not reintroduce the beans.
The static { Registry.setContributionProvider(new ClasspathContributionProvider("com.activeviam.apm","com.activeviam","com.quartetfs","com.qfs")); } block in 5.1.3’s ApplicationConfig is replaced by static { Registry.initialize(Registry.RegistryContributions.builder().build()); } — the explicit package list is gone. If the customization added contribution packages, wire them through the new RegistryContributions.builder() API.
Step 5: POM, Dockerfile, and runtime flags
- Pin nothing. The 6.0.0 parent POM (
common-parent-pom:2.5.0) pluscommon-dependencies-bom:2.5.0manage versions. Explicit versions in customized POMs cause divergence with the Atoti BOM. If a 5.1.3 customization pinneddataconnectors.version,solutions-tools-bom.version,regression-testing.version, orjunit-bom, delete the pin. - The new
cvarc-starter/pom.xmlhas nospring-boot-maven-pluginrepackageexecution. The repackage moved tocvarc-application/pom.xml. Customizations that ran the build viacvarc-starter/target/*-exec.jarmust repoint atcvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar. - Apply the Hibernate group-ID change (
org.hibernate→org.hibernate.orm) in any module POM that pulls Hibernate directly. - Replace
AtotiAuthTokenwithSharedSecretAuthTokenin any custom JGroups protocol XML — see JGroups protocol files. - Apply the JVM flag changes from Java 21 upgrade and the full Dockerfile diff from Docker configuration. Servlet context-path moves from
/cvarc-starterto/cvarc-application.
Step 6: data samples and external fixtures
bookmarks/ (repo root) contents are unchanged between releases. data-samples/ moves from cvarc-starter/data-samples/ to cvarc-application/data-samples/, with unchanged contents. The committed H2 file cvarc-isda-tests/content_service.mv.db is removed in 6.0.0; if the test rig depended on it, regenerate at test setup. Property files relocate from cvarc-starter/src/main/resources/properties/ to cvarc-application/src/main/resources/properties/; activemonitor-support.properties is dropped.
Step 7: build, validate, and debug
Effort budget — Bucket A: minutes per file (3-way merge). Bucket B: 15–60 min per file (port hunk to new module/path). Bucket C: 30 min–2 h per file (write override, verify upstream API). Bucket D: 1–5 days per subsystem (genuine redesign). Tracing, ActiveMonitor, CSV → DLC, and What-If together account for almost all Bucket D calendar time.
Posture shift — stop editing upstream classes in place. The 6.0.0 stack is built around starter auto-config plus
@ConditionalOnMissingBean seams (visible on startManager and InitialDataLoadConfig). Keep customizations as a thin overlay of @Bean overrides, property files, and subclasses of BASourceDescription/SASourceDescription/FileUploadSimulationDefinition. The next upgrade will be much cheaper than this one.
Reference: breaking changes by topic
The following sections provide deeper context for each breaking change area. Migration path steps link here when a specific topic needs investigation.Complete change inventory
Every change pulled in by replacing the 5.1.3 source tree with 6.0.0, in one place. Path A applies all of these by default; Path B and Path C inherit them and add their own per-customization handling.
Net effect: 6.0.0 moves from a hand-wired ActivePivot 6.0 / Sleuth+Brave / Java 17 / Tomcat 9 stack to an Atoti 6.1 / Spring Boot starter / OpenTelemetry / Java 21 / Tomcat 11 stack. The deleted
@Configuration classes are not a regression: their behavior is replicated by the new starters and the DLC local profile, all activated by the default application.yml shipped under cvarc-application/src/main/resources/.
Module rename
The Maven module structure has been reorganized. If a fork or downstream project depends on Atoti CVA Risk Capital modules, updatepom.xml dependencies as follows:
Spring-context integration tests previously in
cvarc-starter are now in the dedicated cvarc-application-tests module. Update CI/CD configuration if test classes are referenced by module.
Main class rename
The main Spring Boot application class has been renamed:Java 21 upgrade
Java 21 is now required. The POM enforcesrequireJavaVersion 21 and the Maven build fails immediately on the wrong JDK.
Two --add-opens flags are now required at launch:
java.base/java.util) is new in 6.0.0. Both must be present for the direct-jar launch. The shipped Dockerfile already includes both.
Jakarta EE migration (javax → jakarta)
Alljavax.* imports have been migrated to jakarta.* as part of the Spring Boot 3 upgrade:
javax.servlet.*→jakarta.servlet.*javax.persistence.*→jakarta.persistence.*javax.validation.*→jakarta.validation.*
javax.servlet:javax.servlet-api with jakarta.servlet:jakarta.servlet-api (scope provided).
Spring security 6 migration
Spring Security 6.x is included as part of the Spring Boot 3 migration. The deprecatedWebSecurityConfigurerAdapter has been replaced with SecurityFilterChain beans:
MvcRequestMatcher.Builder bean is required:
JwtAuthenticationConfigurer and CorsConfig are deleted outright in 6.0.0. CORS is now managed via configuration properties.
OpenTelemetry replaces Spring Sleuth
Spring Cloud Sleuth and Zipkin Brave have been replaced by OpenTelemetry 1.43.0. The following dependencies are added:opentelemetry-spring-boot-starteropentelemetry-sdk-extension-autoconfigureopentelemetry-logback-mdc-1.0
TracingConfig (cvarc-common) and BraveTracingConfig (cvarc-starter) are replaced by OpenTelemetryTracingConfig in cvarc-common-config, already imported by the new ApplicationConfig.
New configuration in application.yml:
@DependsOn(TracingConfig.TRACING_BEAN) pattern from 5.1.3’s ApplicationConfig is removed in 6.0.0.
DispatcherServlet configuration removal
ThedispatcherServletRegistration bean has been removed from CVARCApplication. This bean registered a DispatcherServletRegistrationBean as a workaround for Spring Boot incompatibilities in previous versions of Atoti Server.
This workaround is no longer needed. If a custom application class overrides or references this bean, remove the override.
Atoti Server 6.1.19 starters
The project now uses Atoti Server starters for simplified dependency management. These replace the hand-written configuration classes that were deleted in this release:atoti-server.version explicitly in module POMs.
Swagger UI is now enabled by default (springdoc.swagger-ui.enabled: true in the new application.yml). Disable it via a property override if needed.
Data load controller changes
The data loading framework has been replaced:
Per-cloud CSV source classes (
Ba/Sa/Shared/Crif{Aws,Azure,Google,}CsvSourceConfig) are replaced by the DLC configuration package in cvarc-starter/.../cfg/impl/dlc/ and the new Spring profile YAMLs (application-dlc-local-csv.yaml, application-dlc-azure-csv.yaml). The default csv-source.type: local in application.yml preserves the 5.1.3 local-CSV behavior.
Conditional deployment toggling (dist-data-node / dist-query-node Spring profiles) is replaced by @ConditionalOnDataNode / @ConditionalOnQueryNode. The SP_PROFILE__DATA_NODE and SP_PROFILE__QUERY_NODE constants are removed from CVARCEnvConstants, and the spring.profiles.active property is removed from cvarc.properties.
What-If 2.1.6-AS6.0 → 5.0.0-AS6.1
What-If has been upgraded fromwhatif:2.1.6-AS6.0 to atoti-what-if-lib:5.0.0-AS6.1 plus atoti-what-if-spring-boot-starter. This introduces breaking API changes that affect custom implementations extending WhatIfConfig.
Maven artifact rename: replace com.activeviam.apps:whatif with com.activeviam.apps:atoti-what-if-lib and add com.activeviam.apps:atoti-what-if-spring-boot-starter.
Simulation persistence: Hibernate replaces DataStore
The persistence layer has changed from a DataStore-based manager to a Hibernate/JPA manager.
Before (2.1.6-AS6.0):
@EnableConfigurationProperties({ WhatIfHibernateProperties.class }) to the WhatIfConfig subclass to enable property binding. Default properties use an in-memory H2 database.
Security manager: constructor arguments added
SpringDatabaseSimulationsSecurityManager now requires ISimulationPersistenceManager and IBranchPermissionsManager to be injected:
RestDistributedDatabaseService bean now takes AddressSupplier and AuthenticatorSupplier instead of inline lambdas. Authentication switched from UserAuthenticator (username/password) to JwtAuthenticator (JWT tokens):
In 5.0.0-AS6.1,
AddressSupplier and AuthenticatorSupplier have been removed. Distributed What-If communication for file uploads is now handled by Spring 6 HTTP Service Proxies (RestClientConfig), with JWT tokens propagated automatically.
Update any client code or configuration that calls the What-If REST endpoints directly.
Store coverage expanded
Trade duplication now covers 7 stores (previously Delta only): BaBase, TradeDescription, CapitalTreatment, BAHedgeRisk, SaBase, Delta, Vega.
Trade scaling now covers 3 stores:
Error handling change
All What-If controllers now throw
CVAServiceException with HTTP status codes instead of returning DatabaseSimulationStatus in the response body. REST clients receive 401 Unauthorized or 500 Internal Server Error on failure instead of 200 OK with a FAILED or UNAUTHORISED status body. Update any client code that checks the response body for failure status values.
What-If feature flags
Each What-If operation can be disabled via properties:
Removed What-If classes
CVARCWhatIfSecurityManager: superseded bySpringDatabaseSimulationsSecurityManager.TradeScaleDTO: superseded byTradeRescaleDTO.TradeDuplicateAndRescaleSimulationDefinition: replaced byTradeDuplicateSimulationDefinitionandTradeScalingSimulationDefinition.WhatIfConfig(fromcvarc-common) andWhatIfRestServices: replaced byWhatIfConfigincvarc-application.StressedSensitivitySimulationDefinition,StressedSensitivityWhatIfException,StressedSensitivityWhatIfSubmitter: replaced byFileUploadSimulationDefinitionandFileUploadWhatIfSubmitter.AddressSupplier,AuthenticatorSupplier: superseded by Spring 6 HTTP Service Proxy configuration inRestClientConfig.
- Exception package: What-If REST exceptions (including
CVAServiceException) are now undercom.activeviam.tools.whatif.rest. Update any exception imports in custom code. IDistributedQueryResultsMerger: the interface no longer exposes branch-deletion or fast-forward methods. Remove any custom overrides of those methods; they are handled internally by the new distributed What-If pipeline.- Lombok annotation processor: several base classes in
atoti-what-if-libnow use Lombok. Custom code extending them must declareorg.projectlombok:lombokon the annotation processor classpath, otherwise compilation fails on missing constructors and accessors.
StressedSensitivityWhatIfRestController (activated by @ConditionalOnInMemoryDatabase). Query nodes run StressedSensitivityQueryNodeRestController (activated by @ConditionalOnQueryNode), which orchestrates the upload across all data nodes in parallel.
A new POST /upload-nosim/{branch} endpoint is available on both data and query nodes. It creates a branch and loads data without running a What-If simulation.
No additional configuration is needed. The correct controller is activated automatically based on deployment topology.
Atoti Limits 4.2.1
The Limits add-on has changed GroupId, artifact ID, and version:
The
useLimitsModule property is removed. To re-enable Limits, set limits.autoconfiguration.enabled=true in application.yml or your property override. Custom limit rules need to be re-expressed against the 4.x API.
Hibernate upgrade
The Hibernate dependency group ID has changed:JGroups protocol files
TheAtotiAuthToken class has been replaced with SharedSecretAuthToken. Update all JGroups protocol XML files:
Configuration files (cvarc.properties, application.yml)
cvarc.properties moves from cvarc-starter/src/main/resources/properties/cvarc.properties to cvarc-application/src/main/resources/properties/cvarc.properties.
Removed properties (5.1.3 → 6.0.0):
Added properties (6.0.0):
New
application.yml sections:
CVARCEnvConstants constant renames
Many _SYSPROP / _SYNSPROP / _PROP suffixes were standardized to _PROPERTY:
SAMeasureBuilder constant renames (typo fix SENSITITIVIES → SENSITIVITIES):
M__VEGA_UNFILTERED is removed. Eight formerly public constants are now private. getDatastore() and setDatastore() are removed from SAMeasureBuilder.
Docker configuration
The Dockerfile moves fromcvarc-starter/Dockerfile to cvarc-application/Dockerfile. A docker build cvarc-application/ without pre-copy steps will fail; CI must copy data-samples and bookmarks first (see Path A step 4b).
Full diff of Dockerfile changes:
Migration checklist
Use this checklist to verify a complete migration regardless of path. Build environment- Install JDK 21 and confirm
java -versionreports 21.x. - Confirm
JAVA_HOMEpoints at the JDK 21 installation.
- Replace the 5.1.3 source tree with the 6.0.0 tree (clean checkout — do not forward-merge).
- Update Maven
<artifactId>references using the module rename table. - Replace
CVAWebApplicationwithCVARCApplicationin IDE run configurations, Docker images, and deployment scripts. - If Spring-context tests are in a fork, move them to
cvarc-application-tests.
- Replace all
javax.*imports withjakarta.*(servlet, persistence, validation). - Apply the full find-and-replace regex table from Path C step 3.
- Rename
CVARCEnvConstantsconstants from_SYSPROP/_SYNSPROP/_PROPto_PROPERTY. - Rename the six
SAMeasureBuilderSENSITITIVIESconstants toSENSITIVITIES. - Rename
ReferenceLevelTranslator.KEYtoReferenceLevelTranslator.TRANSLATOR_KEY.
- Remove references to
BraveTracingConfig,TracingConfig,TracingRestServiceConfig, andbrave.Tracing. - Remove references to
JmxMonitoringConfig,MonitoringRestServicesConfig,ApplicationMonitoringConfig. - Remove references to
ActiveMonitorSupportConfig, the ActiveMonitor stack, andactivemonitor-support.properties. - Remove references to all
Ba/Sa/Shared/Crif*CsvSourceConfigclasses andCommonCloudSourceConfig. - Remove references to
LimitsIntegration; if Limits was active, setlimits.autoconfiguration.enabled=true. - Remove references to
DoctorPivotConfig,doctorpivot-{api,web-app}. - Remove
JwtAuthenticationConfigurerandCorsConfig; CORS is now config-driven. - Remove
dispatcherServletRegistrationbean overrides — see DispatcherServlet configuration removal.
- Migrate from
WebSecurityConfigurerAdaptertoSecurityFilterChainbeans. - Add the
MvcRequestMatcher.Builderbean. - Configure
AuthenticationManageras a bean.
- Replace
com.activeviam.apps:whatifwithatoti-what-if-liband addatoti-what-if-spring-boot-starter. - Migrate
persistenceManagerbean toHibernateSimulationPersistenceManager. - Update
securityManagerbean to injectISimulationPersistenceManagerandIBranchPermissionsManager. - Update any
RestDistributedDatabaseServicewiring fromUserAuthenticatortoJwtAuthenticator. - Update REST clients calling
/services/rest/what-if/to/activeviam/what-if/rest/v3. - Update exception imports to
com.activeviam.tools.whatif.rest. - Remove overrides of deleted
IDistributedQueryResultsMergerbranch-deletion and fast-forward methods. - Update imports for
TradeRescaleRestServiceController(moved tocvarc-application). - Remove references to
CVARCWhatIfSecurityManager,TradeScaleDTO, andTradeDuplicateAndRescaleSimulationDefinition. - Update REST clients that check the response body for failure status to handle HTTP error codes instead.
- Ensure Lombok is on the annotation processor classpath if custom code extends affected What-If classes.
- Remove deprecated
cvarc.propertiesentries listed in the configuration files section. - Review
logback.xmlfor compatibility with Logback 1.5.x.
- Replace
AtotiAuthTokenwithSharedSecretAuthTokenin all JGroups protocol XML files.
- Update the jar path from
cvarc-starter/target/…tocvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar. - Replace
-Dactiveviam.chunkAllocatorClass=…MmapDirectChunkAllocatorwith-Dactiveviam.chunkAllocatorKey=mmap. - Add
--add-opens=java.base/java.util=ALL-UNNAMEDto JVM flags. - Drop
--content-service.db.url=…from the launch line. - Add
--csv.topic.path=./data-samples/dataif using the bundled CSV samples. - Update any reverse proxy or client that references the old
/cvarc-startercontext path. - Update Docker base image to
eclipse-temurin:21. - Move the Docker build context from
cvarc-starter/tocvarc-application/; pre-copydata-samplesandbookmarksbefore building.
- Run
mvn -DskipTests clean installfrom the project root. - Start the application and verify it reaches the ready state.
- Verify all security filter chains and What-If simulation flows work correctly.