IM 7.2.0 → 7.3.0 — Internal/Framework Details Part 1 (§13–§19D)

Appendix — Internal / IM Framework Details (Part 1: §13 – §19D)

Parent doc: upgrade-migration-guide-to-im-7-3-0.md
Confluence mirror: IM 7.2 → 7.3.0 — Appendix — Internal / IM Framework Details (Part 1: §13 – §19D)

Internal-only — IM framework developer reference. Customer integrators can skip this section.

13. Docker / Deployment Changes

Base Image

• Old: amazoncorretto:17-al2-jdk

• New: cregistry.pricefx.eu/im/images/toolchains/corretto-mvn:25-202604150757

• The only Dockerfile shipped at v7.3.0 is integration-apps/integration-runner-app/src/main/docker/Dockerfile (the previous v7.2.0 pricefx-integration-app/src/main/docker/Dockerfile was removed when manual IM was retired).

• The :25-… tag refers to the Pricefx toolchain image build identifier, not the Java major version — the JVM inside the image is Java 21.

CDS (Class Data Sharing) — NEW

Docker build now extracts fat JAR and creates a shared class archive for faster startup:

RUN JAR_FILE=$(ls -1 lib/integration-app-*.jar | grep -v sources | head -1) && \
    java -Djarmode=tools -jar "$JAR_FILE" extract --destination app && \
    timeout 120 java -Dspring.context.exit=onRefresh \
        -XX:ArchiveClassesAtExit=app-cds.jsa \
        -jar app/integration-app-*.jar || true

Runtime adds -XX:SharedArchiveFile=app-cds.jsa.

Bootstrap.yml Removal

COPY bootstrap.yml removed from Dockerfile.

DuckDB Cross-Platform

duckdb --version check skipped on arm64 during cross-platform builds.

Trust Store

chown im:customer removed from cacerts copy (simplified permissions).

CI/CD Changes

15. Open Gaps on the Feature Branch (Need Action)

The doc's breaking-change list was cross-checked against the feature/PFIMCORE-2956 branch codebase. The items below are the ones that are not yet addressed and need follow-up before release. (Items already fixed and items that don't apply to IM were tracked during development but are no longer carried in this doc.)

16. Spring Boot 3.1.5 → 3.5.12

Impact: HIGH | Type: Configuration, API, Behavior

This spans Spring Boot 3.2, 3.3, 3.4, and 3.5 — each introduced breaking changes.

16.1 Property Changes

16.2 Deprecated / Removed APIs

16.3 Actuator Changes (Spring Boot 3.2+)

• Info endpoint contributors require explicit enablement:

  management.info.java.enabled=true
  management.info.build.enabled=true
  management.info.git.enabled=true
  

  Previously these were auto-enabled.

16.4 Spring Boot 3.2: Observability Auto-Configuration

• Micrometer Observation API is auto-configured.

• New @Observed annotation support.

• May affect custom metrics.

16.5 Spring Boot 3.3: SSL Bundle Improvements

• SSL auto-configuration changes for TLS/SSL keystores.

• New spring.ssl.bundle.* properties.

16.6 Spring Boot 3.4: RestClient and HTTP Client

• RestClient is the new preferred HTTP client (replaces RestTemplate for new code).

• HttpComponentsClientHttpRequestFactory now uses HttpClient 5 by default.

• spring.http.client.* properties introduced for unified HTTP client configuration.

16.7 Spring Boot 3.4: Actuator Endpoint Access Model Reworked

• Old properties: management.endpoints.enabled-by-default, management.endpoint.<id>.enabled

• New properties: management.endpoints.access.default (values: none/read-only/unrestricted), management.endpoint.<id>.access

• Heapdump endpoint defaults to access=NONE in 3.5.

16.8 Spring Boot 3.5: Strict Boolean Properties

• Boolean .enabled properties now only accept true/false. Values like yes, on, 1, off, no, 0 are rejected.

16.9 Spring Boot 3.5: taskExecutor Bean Alias Removed

• Only applicationTaskExecutor is provided. Code using @Qualifier("taskExecutor") or getBean("taskExecutor") must update.

16.10 Spring Boot 3.5: HikariCP 6.x

• If overriding getPassword() in HikariDataSource, must also override getCredentials().

• JDBC 4.3 beginRequest()/endRequest() support added.

16.11 Spring Boot 3.2: -parameters Compiler Flag Required

• Spring Framework 6.1 removed LocalVariableTableParameterNameDiscoverer. Without -parameters, DI by parameter name, @PathVariable, @RequestParam, SpEL #paramName all break.

• IM Status: Already configured in maven-compiler-plugin.

16.12 Spring Boot 3.2: Nested JAR URL Format Changed

• Old: jar:file:/dir/myjar.jar:BOOT-INF/lib/nested.jar!/...

• New: jar:nested:/dir/myjar.jar/!BOOT-INF/lib/nested.jar!/...

• Launcher class renamed: org.springframework.boot.loader.JarLauncher → org.springframework.boot.loader.launch.JarLauncher

IM Impact (Applied in Branch)

• getRawStatusCode() → .getStatusCode().value() across V2_0.java, V3_1.java (HTTP client code).

• APPLICATION_JSON_UTF8_VALUE → APPLICATION_JSON_VALUE in ConnectionsCompatibilityController.java.

• Base64Utils → java.util.Base64 in MapperConfigurationService.java.

• WsConfigurerAdapter → WsConfigurer in WebServicesSpringAutoConfiguration.java.

• Security configuration completely refactored (see Spring Security section).

• BuildProperties bean now optionally injected in CoreAutoConfiguration.

• Actuator info properties explicitly enabled in default-application.properties.

• <executable>true</executable> removed from spring-boot-maven-plugin in runner and pricefx-integration-app.

17. Spring Framework 6.0 → 6.2

Impact: MEDIUM | Type: API, Behavior

Key Changes

• PathPatternParser is the default for URL pattern matching in Spring MVC (replaces AntPathMatcher). This is the reason for the security matcher migration.

• @Nullable annotations tightened: Some previously nullable return types are now non-null.

• WebMvcConfigurationSupport changes: Some internal method signatures changed.

• Property placeholder parser rewritten (6.2): Keys containing : must be escaped (${sub\\://host}). Placeholders can be escaped (\\${test} → literal ${test}).

• Bean definition overriding stricter (6.2): Component scanning with REGISTER_BEAN conditions fails hard. Set spring.main.allow-bean-definition-overriding=true if needed.

• Invalid @Configuration rejected (6.2): Rejects @Bean methods with void return types and @Bean methods with @Autowired.

• Autowiring algorithm revised (6.2): @Qualifier and parameter name matches now take precedence over @Priority.

• Built-in method validation (6.1): Spring MVC now performs parameter-level validation automatically. May cause MethodValidationException instead of argument resolver validation.

• ClientHttpRequestFactory no longer buffers (6.1): Content-Length may not be set for unknown-size content.

• throwExceptionIfNoHandlerFound defaults to true (6.1): Raises NoHandlerFoundException (404) by default.

IM Impact (Applied in Branch)

• Security matchers migrated from AntPathRequestMatcher/MvcRequestMatcher to string-based requestMatchers() and PathPatternRequestMatcher.

• @NotNull (JetBrains org.jetbrains.annotations.NotNull) replaced with @Nonnull (Jakarta jakarta.annotation.Nonnull) in some places.

• javax.annotation.PostConstruct → jakarta.annotation.PostConstruct.

18. Spring Security 6.1 → 6.5

Impact: HIGH | Type: API, Security Configuration

18.1 Removed / Changed APIs

18.2 Security Configuration Pattern Change

Before (IM 7.2):

public SecurityFilterChain filterChain(HttpSecurity http, HandlerMappingIntrospector introspector, ...) {
    http.requiresChannel(x -> x.anyRequest().requiresSecure())
        .authorizeHttpRequests(x -> {
            x.requestMatchers(AntPathRequestMatcher.antMatcher("/ws/**.wsdl")).permitAll();
            x.requestMatchers(mngmtMatcher(introspector, "/**")).hasRole(ROLE_API);
        });
}
private static MvcRequestMatcher mngmtMatcher(HandlerMappingIntrospector introspector, String pattern) {
    return new MvcRequestMatcher.Builder(introspector).pattern(pattern);
}

After (IM 7.3.0):

public SecurityFilterChain filterChain(HttpSecurity http, AuthenticationManager inMemoryManager, ..., PathMatcher mvcPathMatcher) {
    http.authorizeHttpRequests(x -> {
            x.requestMatchers("/health").permitAll();
            x.requestMatchers("/ws/**.wsdl").permitAll();
            x.requestMatchers("/**").hasRole(ROLE_API);
        });
}
// mngmtMatcher() helper method DELETED

18.3 Authentication Resolver Change

// Old
new Tuple2<>(AntPathRequestMatcher.antMatcher(pattern), pricefxManager)
// New
new Tuple2<>(PathPatternRequestMatcher.withDefaults().matcher(pattern), pricefxManager)

IM Impact (Applied in Branch)

• SecurityAutoConfiguration.java completely refactored:

  • HandlerMappingIntrospector removed from method signature.

  • requiresChannel() (HTTPS enforcement) removed entirely.

  • All AntPathRequestMatcher.antMatcher() replaced with string-based requestMatchers().

  • mngmtMatcher() helper method deleted.

  • /health endpoint explicitly permitted.

  • DaoAuthenticationProvider constructor changed to take UserDetailsService.

• RestAutoConfiguration.java: AntPathRequestMatcher.antMatcher() replaced with string-based matchers.

• Default security credentials now have fallback values: ${integration.user:admin} and ${integration.password:${random.uuid}}.

19. Apache CXF 4.0.3 → 4.1.5

Impact: MEDIUM | Type: API, Dependencies

Changes

• CXF version now managed via BOM in parent POM.

• New explicit dependencies added to pricefx-integration:

  • cxf-rt-frontend-jaxws (JAX-WS frontend)

  • cxf-rt-features-logging (CXF logging feature)

• cxf-rt-transports-http-jetty no longer needs explicit version.

• CxfPayload class relocated to org.apache.camel.component.cxf.common package.

IM Impact (Applied in Branch)

• WebServicesSpringAutoConfiguration: extends WsConfigurerAdapter → implements WsConfigurer.

• CxfPayloadProcessor.java: businessKeysMaxLengths handling removed.

• XmlWithNamespaceSplitter.java: New CXF payload serialization via TransformerFactory.

• New serializeCxfPayload() method handles CxfPayload<Element> → XML String conversion.

19A. Eclipse Jetty 11 → 12 (transitive, EE10)

Impact: MEDIUM | Type: Major-version transitive bump driven by Camel/CXF

What changed (verified via mvn dependency:tree on pricefx-integration for both tags)

Pulled in transitively via:

• org.apache.cxf:cxf-rt-transports-http-jetty:4.1.5 → Jetty 12 core + jetty-ee10-servlet

• org.apache.camel:camel-jetty:4.18.1 → Jetty 12 core + jetty-ee10-servlets + WebSocket variants

Jetty 11 → 12 — what's actually different

• Servlet integration moved to a separate EE module: in Jetty 11, the Servlet API lived in jetty-servlet; in Jetty 12 the core (jetty-server) is Servlet-agnostic and deployment-environment support is layered on via jetty-ee9-* (Servlet 5 / jakarta.servlet.* 5.x) or jetty-ee10-* (Servlet 6 / jakarta.servlet.* 6.x). IM 7.3.0 lands on EE10.

• HandlerCollection / HandlerWrapper removed in favor of Handler.Sequence / Handler.Wrapper.

• Request / Response API rewritten — Jetty's own request and response types no longer extend HttpServletRequest / HttpServletResponse directly; the Servlet bridge is in the EE10 module.

• HttpClient API tightened — Request.method(...) enum-based, removed deprecated string overloads.

• WebSocket API package change — org.eclipse.jetty.websocket.* → org.eclipse.jetty.ee10.websocket.* for the Servlet integration path.

IM Impact

• IM does not embed or configure Jetty directly. All Jetty usage is via camel-jetty (route consumers/producers) and cxf-rt-transports-http-jetty (SOAP web service exposure). Both are upgraded along with their parent libraries.

• Customer routes that use plain jetty:http://… endpoints continue to work — Camel insulates them from the major-version change.

• Customer impact: only customers who write Java/Groovy code that imports org.eclipse.jetty.* directly need to migrate (e.g. custom Handler subclasses, custom HttpClient, embedded Jetty servers). Such code is rare in IM integrations.

Restriction

• The classpath is now Servlet 6 / jakarta.servlet.* 6.x via Jetty EE10. Code or libraries pinned to jakarta.servlet:5.x will fail to resolve at runtime.

19B. CXF WS-Security: WSS4J / OpenSAML / Shibboleth chain (NEW — transitive)

Impact: LOW (mostly classpath bloat) | Type: Transitive additions via CXF 4.1.5

What's new (none of these existed in v7.2.0)

Pulled in via cxf-rt-ws-security (transitive of CXF 4.1.5 — CXF 4.1 began transitively bundling WSS4J 4.x, which itself transitively pulls OpenSAML 5 / Shibboleth 9 / Santuario 4).

IM Impact

• IM does not actively use WS-Security or SAML — these artifacts are dragged onto the runtime classpath whether IM uses them or not. The footprint is ~25 additional JARs (~12 MB).

• No code change required. No customer action required.

• Risk if customers embed or call CXF WS-Security: they should test SAML token validation and signed/encrypted SOAP, since the WSS4J 4.x and OpenSAML 5.x APIs differ from earlier versions.

Restriction

• None for IM-internal code. Classpath bloat is the only practical effect.

19C. Prometheus client library replacement: simpleclient → prometheus-metrics

Impact: LOW for IM (uses Micrometer); MEDIUM for any customer code that imports the client library directly | Type: Library replacement

What changed

Pulled in via io.micrometer:micrometer-registry-prometheus (1.11.5 → 1.15.10), which switched its transitive dependency from the legacy simpleclient family to the new prometheus-metrics family in Micrometer 1.13+.

Prometheus 1.x vs simpleclient — what's different

• simpleclient (started in 2014) is officially deprecated. The new prometheus-metrics library was rewritten in 2023 to be OpenMetrics-compliant and to align naming (counters end in _total, gauges use _ratio, etc.).

• Metric construction APIs have different builders:

  • Old: Counter.build("name", "help").register()

  • New: Counter.builder().name("name").help("help").register(registry)

• Exposition format has dedicated text/protobuf modules (prometheus-metrics-exposition-formats).

IM Impact

• IM does not import io.prometheus.* directly anywhere — all Prometheus exposure is via Micrometer (MeterRegistry), which abstracts the library. Verified: git grep "io\.prometheus\." -- '*.java' '*.groovy' returns no IM hits.

• The /actuator/prometheus endpoint output format is unchanged (still standard Prometheus text exposition); any external scraper continues to work.

• Customer impact: only customers who write Groovy/Java that imports io.prometheus.client.simpleclient.* directly will break. Such code is rare. Migration: switch to the Micrometer MeterRegistry API or to the prometheus-metrics-core builder API.

Restriction

• io.prometheus:simpleclient* artifacts are no longer on the classpath. Any direct usage will fail with ClassNotFoundException.

19D. SnakeYAML 1.25 → 2.6

Impact: MEDIUM | Type: Major-version direct dependency bump in pricefx-integration

What changed

• Direct dependency in pricefx-integration/pom.xml: org.yaml:snakeyaml 1.25 → 2.6.

• Also bumped transitively: org.snakeyaml:snakeyaml-engine 2.7 → 2.9 (separate library by the same author, used by Jackson YAML data format and Spring Boot YAML loaders).

SnakeYAML 1.x → 2.x — what's different

• CVE-2022-1471 hardening: the Constructor class is replaced with SafeConstructor as the default. Arbitrary class instantiation from YAML now requires explicitly opting in via LoaderOptions.setAllowedTags(...) or constructing with Constructor directly.

• Yaml#load(InputStream) no longer accepts polymorphic types by default — attempts to deserialize into an arbitrary Java class will throw ConstructorException unless the class is on the allowed-tag list.

• API tightening: LoaderOptions and DumperOptions are mandatory in many constructors that previously had no-arg variants.

• Yaml.loadAll() returns Iterable<Object> (was Iterable<? extends Object> — minor signature change).

• Deprecated APIs removed — BaseConstructor#getSingleData() signature changed; MarkedYAMLException field exposure tightened.

IM Impact

• IM uses SnakeYAML in two places: connection-definition deserialization (where types are known and explicit) and Camel YAML DSL parsing (Camel manages its own Yaml instance).

• Both call sites use type-bounded deserialization (yaml.loadAs(Foo.class, …)-style or Yaml.loadAs), which is safe-by-default in 2.x. No code change was needed in feature/PFIMCORE-2956, and the v7.2.0..v7.3.0 diff confirms there are no SafeConstructor opt-ins added — the existing call sites already meet the new defaults.

Customer impact / restriction

• Customer Groovy scripts that load YAML with new Yaml().load(...) against a generic Object and rely on polymorphic class instantiation will throw ConstructorException. The fix is to use typed loading (yaml.loadAs(MyClass.class, input)) or pass LoaderOptions.setAllowedTags(...).

• Customer YAML files that contain !!java.lang.… or !net.pricefx.… explicit class tags will be rejected by default.