Migration notes 6.0

This page explains the changes required to migrate from Atoti CVA Risk Capital 5.1.3 to 6.0.0.

For new features and fixes included in this release, see the Atoti CVA Risk Capital 6.0.0 release notes. For Atoti Server changes, see the Atoti Server release notes.

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 requireJavaVersion 21.
• Atoti Server 6.1.19: Upgraded from ActivePivot 6.0.9. All com.qfs.* and com.quartetfs.* package roots move to com.activeviam.{activepivot,tech,database,web}.*.
• Spring Boot 3 / Jakarta EE 10: javax.* replaced by jakarta.* across the board.
• Spring Security 6: WebSecurityConfigurerAdapter removed; replaced by SecurityFilterChain beans.
• OpenTelemetry 1.43.0: Spring Cloud Sleuth and Zipkin Brave removed.
• Module restructuring: 5 modules become 8. cvarc-application is the new executable; cvarc-starter becomes 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.

Smaller breaking changes apply to specific audiences: DispatcherServlet configuration removal (only if a fork overrode the bean), JGroups protocol files (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 via requireJavaVersion in the root POM. The Maven build fails immediately on the wrong JDK.

# verify before building
java -version          # must report 21.x
mvn -version           # "Java version" must be 21.x
export JAVA_HOME=/path/to/jdk-21

No Java 21 language features are required by the upgrade itself. This is a toolchain bump driven by the Atoti Server 6.1.19 stack.

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:

mvn clean install

The new executable jar is:

cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar

5.1.3 produced 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):

java \
  -Dactiveviam.chunkAllocatorClass=com.qfs.chunk.direct.allocator.impl.MmapDirectChunkAllocator \
  --add-opens java.base/java.util.concurrent=ALL-UNNAMED \
  -jar cvarc-starter/target/cvarc-starter-5.1.3-exec.jar \
  --content-service.db.url='jdbc:h2:file:./content_service;DB_CLOSE_DELAY=-1' \
  --contentServer.factory-reset=folder \
  --contentServer.factory-reset.folder-name=file:./bookmarks

New (6.0.0):

java \
  -Xms1024m -Xmx2048m -Xss5m \
  -Dactiveviam.chunkAllocatorKey=mmap \
  --add-opens=java.base/java.util.concurrent=ALL-UNNAMED \
  --add-opens=java.base/java.util=ALL-UNNAMED \
  -jar cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar \
  --contentServer.factory-reset=folder \
  --contentServer.factory-reset.folder-name=file:./bookmarks \
  --csv.topic.path=./data-samples/data

Key differences:

• 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-UNNAMED is a new required flag.
• --content-service.db.url=… is no longer needed — now configured in application.yml.
• --csv.topic.path is new, pointing the Data Load Controller at the CSV samples directory.
• Spring Boot context path moves from /cvarc-starter to /cvarc-application. Update any client or proxy pointing at the old path.

Step 4b: Update your launch command — Docker

The Dockerfile has moved from cvarc-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:

# pre-copy the data the Dockerfile expects
cp -r cvarc-application-tests/src/test/resources/data-samples cvarc-application/src/test/resources/
cp -r bookmarks cvarc-application/src/main/resources/

# build and run
docker build -t cvarc:6.0.0 cvarc-application/
docker run --rm -p 9090:9090 cvarc:6.0.0

A direct 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-root bookmarks/ 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 @Configuration class with @Bean methods, wired by exactly one @Import(...) line on 5.1.3’s ApplicationConfig.
• 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* and ActiveMonitor* (JmxMonitoringConfig, MonitoringRestServicesConfig, ApplicationMonitoringConfig, ActiveMonitorSupportConfig), *CsvSourceConfig, DataLoadControllerConfig, DatastoreConfig, LimitsIntegration, JwtAuthenticationConfigurer, CorsConfig, WhatIfConfig (cvarc-common), WhatIfRestServices, CVARCWhatIfSecurityManager, DoctorPivotConfig, CVAI18nConfig, and I18nConfig. See Step 5 for the full list with replacement guidance.
• It does not customize util.ReferenceLevelUtils (deleted with no upstream replacement). Other ReferenceLevel* types moved upstream to com.activeviam.accelerator.common.{context,postprocessor}.* — Path A still applies if you’re comfortable doing the import rename.
• JDK 21 runtime is acceptable.

If any of those conditions does not hold, follow Path C instead.

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.0 to 2.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-common splits into cvarc-common-lib + cvarc-common-config; cvarc-ba-activepivot → cvarc-ba-config; cvarc-sa-activepivot → cvarc-sa-config; cvarc-starter is demoted from executable to auto-config library; the new cvarc-application module owns the executable plus the main ApplicationConfig. Replaying these renames over a 5.1.3 checkout is more work than dropping one file into the new tree.
• The @Import graph is now centered on cvarc-application/.../cfg/ApplicationConfig.java with 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 from CVAWebApplication (@Configuration @EnableAutoConfiguration @EnableWebMvc, hand-rolling several DispatcherServlet/Filter/ServletContextInitializer beans) to CVARCApplication (@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

Open cvarc-application/src/main/java/com/activeviam/cvarc/application/cfg/ApplicationConfig.java and add the class to the existing @Import list:

@Import(value = {
        ParameterRetrieverConfig.class,
        DatastoreCustomisationsConfig.class,
        SecurityConfig.class,
        // …
        ActivePivotWithDatastoreConfig.class,

        MyCustomConfig.class,        // <-- add this line
})

Add the corresponding 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

Run mvn -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 behaviour 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), and activemonitor-support.properties.
• CSV sources — Ba{Aws,Azure,Google,}CsvSourceConfig, Sa{Aws,Azure,Google,}CsvSourceConfig, Shared{Aws,Azure,Google,}CsvSourceConfig, Crif{,Azure}CsvSourceConfig, CommonCloudSourceConfig, and the ACsvSourceConfig family.
• Data load — DataLoadControllerConfig, InitialDataLoadConfig (the first is gone; the second is reshaped under cvarc-starter/.../cfg/impl/dlc/).
• Security — JwtAuthenticationConfigurer and CorsConfig are deleted outright; CORS is now config-driven. All other security classes have relocated from cvarc-starter/.../security/ to cvarc-application/.../security/ with the same class names.
• What-If — WhatIfConfig (cvarc-common copy), WhatIfRestServices. Controllers (StressedSensitivityWhatIfRestController, ParameterSetRestServiceController, TradeRescaleRestServiceController) relocated to cvarc-application/.../whatif/ with the same names.
• Limits — LimitsIntegration. The new limits-auto-config-61 starter is auto-wired but disabled by default; set limits.autoconfiguration.enabled=true if 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 to com.activeviam.accelerator.common.{context,postprocessor}.* — see Bucket C for the import rename. util.ReferenceLevelUtils was 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 into cvarc-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, and cvarc-starter as 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-api to jakarta.servlet:jakarta.servlet-api (scope provided).

Step 7: Update the Dockerfile (only if a custom Dockerfile is maintained)

The shipped Dockerfile moves from cvarc-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

mvn -DskipTests clean install
java -jar cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar

Common startup failures and which step resolves each:

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:

git -C 5.1.3-clean checkout v5.1.3
diff -ruN 5.1.3-clean/ your-5.1.3-checkout/ > customizations.patch

Then split 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, the com.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.

git checkout v6.0.0
mvn -version   # must report Java 21

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’s ApplicationConfig @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:

mvn -DskipTests -pl cvarc-common-lib,cvarc-common-config,cvarc-ba-config,cvarc-sa-config,cvarc-starter,cvarc-application compile

Let the compiler drive the long tail of remaining renames.

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) plus common-dependencies-bom:2.5.0 manage versions. Explicit versions in customized POMs cause divergence with the Atoti BOM. If a 5.1.3 customization pinned dataconnectors.version, solutions-tools-bom.version, regression-testing.version, or junit-bom, delete the pin.
• The new cvarc-starter/pom.xml has no spring-boot-maven-plugin repackage execution. The repackage moved to cvarc-application/pom.xml. Customizations that ran the build via cvarc-starter/target/*-exec.jar must repoint at cvarc-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 AtotiAuthToken with SharedSecretAuthToken in 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-starter to /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

mvn -DskipTests clean install
java -jar cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar

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 behaviour 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, update pom.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:

// Before (5.1.x)
com.activeviam.cvarc.starter.CVAWebApplication

// After (6.0.x)
com.activeviam.cvarc.application.CVARCApplication

Update references in IDE run configurations, Docker images, and deployment scripts.

Java 21 upgrade

Java 21 is now required. The POM enforces requireJavaVersion 21 and the Maven build fails immediately on the wrong JDK.

Two --add-opens flags are now required at launch:

--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED

The second flag (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)

All javax.* 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.*

Update all affected imports in custom code. In POMs, replace javax.servlet:javax.servlet-api with jakarta.servlet:jakarta.servlet-api (scope provided).

// Before (5.1.x)
import javax.servlet.http.HttpServletRequest;
import javax.servlet.ServletContext;

// After (6.0.x)
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.ServletContext;

Spring Security 6 migration

Spring Security 6.x is included as part of the Spring Boot 3 migration. The deprecated WebSecurityConfigurerAdapter has been replaced with SecurityFilterChain beans:

// Before (5.1.x)
public abstract class AJwtSecurityConfigurer extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .antMatcher(JwtRestServiceConfig.REST_API_URL_PREFIX + "/**")
            .csrf().disable()
            .cors().and()
            .authorizeRequests()
            .antMatchers("/**").hasAnyAuthority(APP_ROLE__USER)
            .and()
            .httpBasic().authenticationEntryPoint(authenticationEntryPoint);
    }
}

// After (6.0.x)
@Bean
@Order(3)
protected SecurityFilterChain jwtSecurityFilterChain(HttpSecurity http, MvcRequestMatcher.Builder mvc) throws Exception {
    return http
        .csrf(AbstractHttpConfigurer::disable)
        .cors(Customizer.withDefaults())
        .securityMatcher(mvc.pattern(url(JwtRestServiceConfig.REST_API_URL_PREFIX + "/**")))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers(mvc.pattern(HttpMethod.OPTIONS, "**")).permitAll()
            .anyRequest().hasAnyAuthority(APP_ROLE__USER))
        .httpBasic(basic -> basic.authenticationEntryPoint(new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED)))
        .build();
}

A new MvcRequestMatcher.Builder bean is required:

@Bean
@Scope("prototype")
MvcRequestMatcher.Builder mvc(HandlerMappingIntrospector introspector) {
    return new MvcRequestMatcher.Builder(introspector);
}

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-starter
• opentelemetry-sdk-extension-autoconfigure
• opentelemetry-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:

otel:
  instrumentation:
    annotations:
      enabled: false

tracing:
  enabled: true

For span creation in custom code, replace:

// Before (5.1.x)
@Autowired
brave.Tracing tracing;
// ...
brave.Span span = tracing.tracer().nextSpan();

With:

// After (6.0.x)
var tracer = io.opentelemetry.api.GlobalOpenTelemetry.getTracer("my-instrumentation");
var span = tracer.spanBuilder("my-span").startSpan();

The @DependsOn(TracingConfig.TRACING_BEAN) pattern from 5.1.3’s ApplicationConfig is removed in 6.0.0.

DispatcherServlet configuration removal

The dispatcherServletRegistration 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:

<dependency>
    <groupId>com.activeviam.springboot</groupId>
    <artifactId>atoti-server-starter</artifactId>
</dependency>
<dependency>
    <groupId>com.activeviam.springboot</groupId>
    <artifactId>atoti-ui-starter</artifactId>
</dependency>
<dependency>
    <groupId>com.activeviam.springboot</groupId>
    <artifactId>atoti-admin-ui-starter</artifactId>
</dependency>

Version management is handled by the parent BOM. Do not pin 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 behaviour.

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 from whatif: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):

@Bean
public ISimulationPersistenceManager persistenceManager(IDatabaseService databaseService) {
    DatabaseSimulationPersistenceManager persistenceManager = new DatabaseSimulationPersistenceManager();
    persistenceManager.setDatabaseService(databaseService);
    return persistenceManager;
}

After (5.0.0):

@Bean
public ISimulationPersistenceManager persistenceManager(WhatIfHibernateProperties whatIfHibernateProperties) {
    var configuration = new org.hibernate.cfg.Configuration();
    var properties = new Properties();
    properties.putAll(whatIfHibernateProperties.getPersistence());
    configuration.addProperties(properties);
    configuration.addAnnotatedClass(DatabaseSimulationJPA.class);
    var sessionFactory = configuration.buildSessionFactory();

    HibernateSimulationPersistenceManager<DatabaseSimulationJPA> persistenceManager =
            HibernateSimulationPersistenceManager.of(DatabaseSimulationJPA.class);
    persistenceManager.setSessionFactory(sessionFactory);
    return persistenceManager;
}

Add @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:

// Before (2.1.6-AS6.0)
@Bean
public IDatabaseSimulationsSecurityManager securityManager() {
    return new SpringDatabaseSimulationsSecurityManager();
}

// After (5.0.0)
@Bean
public IDatabaseSimulationsSecurityManager securityManager(
        ISimulationPersistenceManager persistenceManager,
        IBranchPermissionsManager branchPermissionsManager) {
    return new SpringDatabaseSimulationsSecurityManager(persistenceManager, branchPermissionsManager);
}

Distributed REST service: JWT replaces username/password

The RestDistributedDatabaseService bean now takes AddressSupplier and AuthenticatorSupplier instead of inline lambdas. Authentication switched from UserAuthenticator (username/password) to JwtAuthenticator (JWT tokens):

// After (5.0.0)
@Bean
@Profile("WhatIf")
@ConditionalOnMissingBean
public AddressSupplier addressSupplier() {
    return () -> mvPivot.getClusterMembersRestAddresses().values().stream()
            .map(addr -> addr.regionMatches(true, 0, "http", 0, 4) ? addr : ("http://" + addr))
            .collect(Collectors.toSet());
}

@Bean
@Profile("WhatIf")
@ConditionalOnMissingBean
public AuthenticatorSupplier authenticatorSupplier(IJwtService jwtService) {
    return () -> new JwtAuthenticator(jwtService);
}

@Bean
@Primary
@Profile("WhatIf")
public IDatabaseService restRemoteService(AddressSupplier addressSupplier, AuthenticatorSupplier authenticatorSupplier) {
    return new RestDistributedDatabaseService(addressSupplier, authenticatorSupplier);
}

REST API path change

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 by SpringDatabaseSimulationsSecurityManager.
• TradeScaleDTO: superseded by TradeRescaleDTO.
• TradeDuplicateAndRescaleSimulationDefinition: replaced by TradeDuplicateSimulationDefinition and TradeScalingSimulationDefinition.
• WhatIfConfig (from cvarc-common) and WhatIfRestServices: replaced by WhatIfConfig in cvarc-application.
• StressedSensitivitySimulationDefinition, StressedSensitivityWhatIfException, StressedSensitivityWhatIfSubmitter: replaced by FileUploadSimulationDefinition and FileUploadWhatIfSubmitter.
• AddressSupplier, AuthenticatorSupplier: superseded by Spring 6 HTTP Service Proxy configuration in RestClientConfig.

Other API changes affecting custom What-If code

• Exception package: What-If REST exceptions (including CVAServiceException) are now under com.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-lib now use Lombok. Custom code extending them must declare org.projectlombok:lombok on the annotation processor classpath, otherwise compilation fails on missing constructors and accessors.

Distributed file upload

File-upload What-If now supports distributed deployments. Data nodes run 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:

<!-- Before (5.1.x) -->
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-c3p0</artifactId>
</dependency>

<!-- After (6.0.x) -->
<dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-c3p0</artifactId>
</dependency>

Version management is handled by the parent BOM.

JGroups protocol files

The AtotiAuthToken class has been replaced with SharedSecretAuthToken. Update all JGroups protocol XML files:

<!-- Before (5.1.x) -->
<AUTH auth_class="com.activeviam.activepivot.dist.impl.internal.distribution.security.impl.AtotiAuthToken"
      auth_token.auth_value="distribution_password"
      auth_token.token_hash="SHA"/>

<!-- After (6.0.x) -->
<AUTH auth_class="com.activeviam.common.distribution.security.SharedSecretAuthToken"
      auth_token.auth_value="distribution_password"
      auth_token.token_hash="SHA"/>

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 from cvarc-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

1. Install JDK 21 and confirm java -version reports 21.x.
2. Confirm JAVA_HOME points at the JDK 21 installation.

Source tree and modules

3. Replace the 5.1.3 source tree with the 6.0.0 tree (clean checkout — do not forward-merge).
4. Update Maven <artifactId> references using the module rename table.
5. Replace CVAWebApplication with CVARCApplication in IDE run configurations, Docker images, and deployment scripts.
6. If Spring-context tests are in a fork, move them to cvarc-application-tests.

Imports and symbol renames

7. Replace all javax.* imports with jakarta.* (servlet, persistence, validation).
8. Apply the full find-and-replace regex table from Path C step 3.
9. Rename CVARCEnvConstants constants from _SYSPROP/_SYNSPROP/_PROP to _PROPERTY.
10. Rename the six SAMeasureBuilder SENSITITIVIES constants to SENSITIVITIES.
11. Rename ReferenceLevelTranslator.KEY to ReferenceLevelTranslator.TRANSLATOR_KEY.

Deleted and relocated configs

12. Remove references to BraveTracingConfig, TracingConfig, TracingRestServiceConfig, and brave.Tracing.
13. Remove references to JmxMonitoringConfig, MonitoringRestServicesConfig, ApplicationMonitoringConfig.
14. Remove references to ActiveMonitorSupportConfig, the ActiveMonitor stack, and activemonitor-support.properties.
15. Remove references to all Ba/Sa/Shared/Crif*CsvSourceConfig classes and CommonCloudSourceConfig.
16. Remove references to LimitsIntegration; if Limits was active, set limits.autoconfiguration.enabled=true.
17. Remove references to DoctorPivotConfig, doctorpivot-{api,web-app}.
18. Remove JwtAuthenticationConfigurer and CorsConfig; CORS is now config-driven.
19. Remove dispatcherServletRegistration bean overrides — see DispatcherServlet configuration removal.

Spring Security 6

20. Migrate from WebSecurityConfigurerAdapter to SecurityFilterChain beans.
21. Add the MvcRequestMatcher.Builder bean.
22. Configure AuthenticationManager as a bean.

What-If

23. Replace com.activeviam.apps:whatif with atoti-what-if-lib and add atoti-what-if-spring-boot-starter.
24. Migrate persistenceManager bean to HibernateSimulationPersistenceManager.
25. Update securityManager bean to inject ISimulationPersistenceManager and IBranchPermissionsManager.
26. Update any RestDistributedDatabaseService wiring from UserAuthenticator to JwtAuthenticator.
27. Update REST clients calling /services/rest/what-if/ to /activeviam/what-if/rest/v3.
28. Update exception imports to com.activeviam.tools.whatif.rest.
29. Remove overrides of deleted IDistributedQueryResultsMerger branch-deletion and fast-forward methods.
30. Update imports for TradeRescaleRestServiceController (moved to cvarc-application).
31. Remove references to CVARCWhatIfSecurityManager, TradeScaleDTO, and TradeDuplicateAndRescaleSimulationDefinition.
32. Update REST clients that check the response body for failure status to handle HTTP error codes instead.
33. Ensure Lombok is on the annotation processor classpath if custom code extends affected What-If classes.

Properties

34. Remove deprecated cvarc.properties entries listed in the configuration files section.
35. Review logback.xml for compatibility with Logback 1.5.x.

JGroups

36. Replace AtotiAuthToken with SharedSecretAuthToken in all JGroups protocol XML files.

Launch command and Docker

37. Update the jar path from cvarc-starter/target/… to cvarc-application/target/cvarc-application-6.0.0-SNAPSHOT-exec.jar.
38. Replace -Dactiveviam.chunkAllocatorClass=…MmapDirectChunkAllocator with -Dactiveviam.chunkAllocatorKey=mmap.
39. Add --add-opens=java.base/java.util=ALL-UNNAMED to JVM flags.
40. Drop --content-service.db.url=… from the launch line.
41. Add --csv.topic.path=./data-samples/data if using the bundled CSV samples.
42. Update any reverse proxy or client that references the old /cvarc-starter context path.
43. Update Docker base image to eclipse-temurin:21.
44. Move the Docker build context from cvarc-starter/ to cvarc-application/; pre-copy data-samples and bookmarks before building.

Validation

45. Run mvn -DskipTests clean install from the project root.
46. Start the application and verify it reaches the ready state.
47. Verify all security filter chains and What-If simulation flows work correctly.