IM 7.2 → 7.3.0 — Customer-facing Breaking Changes (§3 details)

Customer-facing Breaking Changes — Detailed Restrictions (§3.1 – §3.34)

Parent doc: upgrade-migration-guide-to-im-7-3-0.md
Confluence mirror: IM 7.2 → 7.3.0 — Customer-facing Breaking Changes — Detailed Restrictions (§3.1 – §3.34)

This page contains the per-restriction detail entries. For the at-a-glance summary tables and the Customer Migration Checklist, see the parent doc.

3.1 Jackson JSON Processing Limits (NEW)

Jackson 2.15+ introduced StreamReadConstraints — hard limits on JSON parsing that did not exist before.

Impact on IM: JSON payloads exceeding these limits will throw StreamConstraintsException at runtime. This affects:

• PFX event consumption with large outputsjson payloads

• Large API responses from Pricefx platform

• Any route processing JSON data > 20 MB in a single string field

Mitigation: Set integration.jackson.max-string-length=-1 in properties to disable string length limit. Other limits are generally safe for IM workloads.

3.2 Jackson String-to-Number Coercion Restricted (NEW)

Jackson 2.19+ disables String-to-number coercion by default. Previously, a JSON value "0" (string) would be silently coerced to integer 0. Now it throws MismatchedInputException.

Impact on IM: The Pricefx API returns some integer fields as strings (e.g., status "0"). Without explicit coercion configuration, API deserialization fails.

Mitigation applied: The ApiClient.mustache codegen template now configures:

json.getMapper().coercionConfigDefaults()
    .setCoercion(CoercionInputShape.String, CoercionAction.TryConvert);

This restores backward-compatible behavior only for the generated PriceFx API client. Custom ObjectMapper instances in customer Groovy scripts or Java code are NOT covered — they get the restrictive default.

Customer impact: If customer Groovy scripts create their own ObjectMapper and parse JSON with string-typed numbers, they must add coercion configuration explicitly.

Customer fix — apply to any custom ObjectMapper:

import com.fasterxml.jackson.databind.ObjectMapper
import com.fasterxml.jackson.databind.cfg.CoercionAction
import com.fasterxml.jackson.databind.cfg.CoercionInputShape

def mapper = new ObjectMapper()
mapper.coercionConfigDefaults()
      .setCoercion(CoercionInputShape.String, CoercionAction.TryConvert)
// ... continue with mapper.readValue(...) as before

Without this snippet, JSON like {"status":"0"} deserialized into a Map<String,Integer> (or any field typed as a number) will throw MismatchedInputException in IM 7.3.0 where it silently coerced in IM 7.2.

3.3 HTTPS Enforcement Removed at Application Level (CHANGED)

IM 7.2 enforced HTTPS via Spring Security:

http.requiresChannel(x -> x.anyRequest().requiresSecure())

IM 7.3.0 removes this entirely — the requiresChannel() API was removed in Spring Security 6.4.

Impact on IM: The application no longer redirects HTTP → HTTPS or rejects plain HTTP requests. HTTPS enforcement must now be handled at the infrastructure level (reverse proxy, load balancer, Kubernetes Ingress).

Restriction: Deployments that relied on IM itself to enforce HTTPS will now accept plain HTTP connections unless the infrastructure enforces TLS.

3.4 BouncyCastle / Encrypted Connection Passwords (RESOLVED — no customer action required)

This was a transient issue during the upgrade work and has been fully resolved before release. It is documented here for awareness only — existing IM 7.2 encrypted connection passwords decrypt unchanged on IM 7.3.0; no re-encryption is needed.

• BouncyCastle 1.78–1.80 introduced a strict IV-length check on CBC-mode PBE that broke Jasypt's NoIvGenerator. The IM upgrade transitively pulled in BC 1.80 via spring-cloud-starter, which would have made encrypted connection passwords from IM 7.2 undecryptable on IaaS workers.

• BouncyCastle 1.81+ restored backward compatibility — see bc-java#1985.

• PFIMCORE-2971 pins bcprov-jdk18on to 1.83 in pricefx-integration/pom.xml, overriding the transitive 1.80. A short-lived encryptor.setIvGenerator(new RandomIvGenerator()) workaround that briefly existed in ConnectionLookup.inlinedConnectionEncryptor was removed by the same fix — the orchestrator (encrypt side) and worker (decrypt side) must use the same IV scheme, and keeping both on no-IV avoids re-encrypting any existing passwords.

Outcome: customers do not need to re-encrypt or rotate any connection credentials when moving from IM 7.2 to 7.3.0.

3.5 Bootstrap Context Removed (BREAKING)

IM 7.2 used bootstrap.yml for Spring Cloud Config Server connection (early initialization).

IM 7.3.0 removes all bootstrap.yml files and the spring-cloud-starter-bootstrap dependency. Config server connection uses spring.config.import=optional:configserver:.

Restriction: Customer projects that include their own bootstrap.yml must delete it and move properties to application.properties. The bootstrap context no longer exists — properties placed in bootstrap.yml will be silently ignored.

3.6 Graceful Shutdown Now Default (CHANGED DEFAULT)

IM 7.2: server.shutdown=immediate (default) — application exits immediately on shutdown signal.

IM 7.3.0: server.shutdown=graceful (Spring Boot 3.4 new default) — application waits for in-flight requests to complete before shutting down (default timeout 30s).

Impact on IM: Shutdown takes longer. Kubernetes pods will not terminate instantly on SIGTERM. This is generally beneficial for Camel route completion but may affect:

• Rolling deployments (pods stay alive longer)

• Kubernetes terminationGracePeriodSeconds configuration

• Health check timing during shutdown

Mitigation: Set server.shutdown=immediate in properties to restore old behavior.

3.7 HTTP Clients Follow Redirects by Default (CHANGED DEFAULT)

IM 7.2: HTTP redirect following was disabled by default for WebClient and RestTemplate.

IM 7.3.0: Spring Boot 3.4 enables redirect following by default for all HTTP clients.

Impact on IM: If IM communicates with external APIs (e.g., Pricefx platform, SFTP proxies, REST endpoints) that issue 3xx redirects, IM will now silently follow them instead of returning the redirect response to the caller. This could cause:

• Unexpected endpoint resolution (following redirects to different servers)

• Authentication header leakage to redirect targets

• Changed response content if redirect leads to a different resource

Mitigation: Set spring.http.client.redirects=dont-follow in properties to restore old behavior.

3.8 Camel FTP Producer Health Checks (NEW)

Camel 4.17 added health checks to the FTP/SFTP producer component. If an FTP producer fails, it may report the route as DOWN in health checks.

Impact on IM: IM uses FTP/SFTP for file-based integrations. A transient FTP connection failure could cause:

• Health check reporting DOWN

• Kubernetes restarting the pod due to failed health probe

• Cascading restarts during temporary SFTP outages

Current configuration: camel.health.routesEnabled=false and camel.health.consumersEnabled=false are already set, but there is no explicit camel.health.producersEnabled=false on the feature branch.

Mitigation: If FTP producer health checks cause issues, add camel.health.producersEnabled=false to properties.

3.9 Camel File Component: eagerMaxMessagesPerPoll Default Changed (CHANGED DEFAULT)

IM 7.2 (Camel 4.1): eagerMaxMessagesPerPoll=false — when using maxMessagesPerPoll with file sorting, all files are first listed and sorted, then the limit is applied.

IM 7.3.0 (Camel 4.18): eagerMaxMessagesPerPoll=true — the limit is applied before sorting. This means if you have 1000 files sorted by name and maxMessagesPerPoll=100, you may get 100 random files instead of the first 100 alphabetically.

Impact on IM: Customer routes using maxMessagesPerPoll with sortBy will get different results. The IM framework does not use maxMessagesPerPoll in its internal routes, but customer routes may.

Mitigation: Customer routes must explicitly set eagerMaxMessagesPerPoll=false if they rely on sort-then-limit behavior.

3.10 Camel Simple Language Operators Removed (REMOVED CAPABILITY)

Camel 4.18 removed deprecated Simple language binary operators:

Impact on IM: IM's internal routes do NOT use these operators (verified). However, customer XML routes deployed via IM may use them. These routes will fail at runtime with a parse error.

Restriction: No backward compatibility — old operator syntax is rejected.

3.11 Camel YAML DSL Kebab-Case Removed (REMOVED CAPABILITY)

Camel 4.13 removed kebab-case support in YAML DSL entirely.

Impact on IM: IM's internal kamelets have been migrated to camelCase. However, customer kamelets (.kamelet.yaml files) using kebab-case (set-header, set-body, etc.) will fail at deploy time.

Restriction: No backward compatibility — kebab-case in YAML DSL is rejected.

3.12 Camel camel.springboot.* Properties Removed (REMOVED CAPABILITY)

Camel 4.13 completely removed the camel.springboot.* property prefix.

Impact on IM: IM's internal properties are migrated. However, customer properties set via config server or application.properties using camel.springboot.* prefix will be silently ignored.

Restriction: No backward compatibility — camel.springboot.* properties have no effect.

3.13 Camel Intercept <when> → <onWhen> (REMOVED CAPABILITY)

Camel 4.10 renamed <when> to <onWhen> inside <intercept> and <interceptSendToEndpoint>.

Impact on IM: IM does not use intercept internally (verified). Customer routes using this pattern will fail at deploy time.

3.14 Camel Load Balancer DSL Names Changed (REMOVED CAPABILITY)

Camel 4.7 renamed load balancer elements (e.g., <failOver> → <failoverLoadBalancer>).

Impact on IM: IM does not use load balancers internally (verified). Customer routes using old names will fail at deploy time.

3.15 Camel Jackson Default Unmarshal Type Changed (CHANGED DEFAULT)

IM 7.2 (Camel 4.1): camel-jackson default unmarshalType = HashMap.

IM 7.3.0 (Camel 4.18): camel-jackson default unmarshalType = LinkedHashMap.

Impact on IM: JSON unmarshalled via Camel's Jackson data format now preserves key insertion order. Code that compared against HashMap class or assumed non-deterministic iteration will behave differently. This is generally a positive change but could affect tests or code that explicitly checks instanceof HashMap.

3.16 Camel Secrets Manager Delimiter Changed (CHANGED SYNTAX)

IM 7.2: {{aws:database/username}} (forward slash delimiter).

IM 7.3.0: {{aws:database#username}} (hash delimiter).

Impact on IM: IM does not use secrets manager syntax internally (verified). Customer routes or properties using vault secret references with / delimiter will get the literal string instead of the resolved secret.

3.17 Kubernetes Client Default HTTP Transport Changed (CHANGED DEFAULT)

IM 7.2 (Fabric8 6.x): Default HTTP client = OkHttp.

IM 7.3.0 (Fabric8 7.x): Default HTTP client = Vert.x.

Impact on IM: The Kubernetes client used for ConfigMap watching and container operations now uses Vert.x instead of OkHttp. This could affect:

• Connection pooling behavior

• TLS/SSL handling

• Proxy configuration

• Timeout defaults

Mitigation: To keep OkHttp, add kubernetes-httpclient-okhttp dependency and exclude Vert.x.

3.18 Jolokia 1.x → 2.x API Change (CHANGED API)

IM 7.2: Jolokia 1.6.2 (jolokia-core artifact).

IM 7.3.0: Jolokia 2.5.0 (jolokia-support-springboot3 artifact).

Impact on IM: The /jolokia actuator endpoint response format changed. Monitoring tools or scripts that parse Jolokia responses may break. Jolokia 2.x uses a different agent configuration format.

3.19 Removed Dependencies — No Longer Available at Runtime

3.20 Java 21 — Removed/Changed JDK APIs

3.21 Spring Boot Boolean Property Validation Strict (NEW)

IM 7.3.0 (Spring Boot 3.5): Boolean .enabled properties only accept true or false. Values like yes, on, 1, off, no, 0 are rejected.

Impact on IM: IM's own properties all use true/false (verified). Customer properties using non-standard boolean values will cause startup failure.

3.22 Spring Security Default Credentials Changed (CHANGED DEFAULT)

IM 7.2: integration.user and integration.password were required properties with no defaults — missing them caused startup failure.

IM 7.3.0: Defaults added:

spring.security.user.name=${integration.user:admin}
spring.security.user.password=${integration.password:${random.uuid}}

Impact: If integration.user and integration.password are not provided, IM starts with user admin and a random UUID password. This is convenient for development but is a security risk in production if accidentally deployed without credentials.

3.23 PFX-API businessKeysMaxLengths URI Parameter Removed (REMOVED CAPABILITY)

IM 7.2: pfx-api:loaddata and pfx-api:integrate accepted a businessKeysMaxLengths URI parameter (and a pfxBusinessKeysMaxLengths header override) that enforced max-length validation on business-key fields client-side.

IM 7.3.0 (PFIMCORE-2862, commit 559fbc0): The Pricefx server API now validates business-key constraints natively. The client-side parameter is no longer accepted — RouteContext.businessKeyLengths was removed and the general-data-load-route.vm template no longer generates the parameter.

Impact on customers: Routes that include &businessKeysMaxLengths=… in a pfx-api: URI, or build the parameter indirectly via <setHeader name="businessKeysMaxLengthsClause"> referenced as ${headers.businessKeysMaxLengthsClause}, will fail at deploy time on IM 7.3.0.

Customer migration:

• Direct case — remove &businessKeysMaxLengths=<value> from any pfx-api: URI:

  XML

  <!-- before -->
  <to uri="pfx-api:loaddata?objectType=P&amp;mapper=m&amp;businessKeys=sku&amp;businessKeysMaxLengths=50"/>
  <!-- after -->
  <to uri="pfx-api:loaddata?objectType=P&amp;mapper=m&amp;businessKeys=sku"/>
  

• Indirect case (meta-route pattern) — remove the ${headers.businessKeysMaxLengthsClause} reference from URIs and delete the now-dead <setHeader name="businessKeysMaxLengthsClause"> block. Also clean up any feeding *.businesskeys.length properties.

The PFIMCORE-2957 upgrade script handles the URI parameter strip and the ${headers.…} reference automatically; the dead <setHeader> block is left for the customer to delete (its placement inside <choice>/<when> wrappers varies — risky to auto-remove). The script reports the block as an advisory in analysis mode.

3.24 Apache HttpClient 4.x → 5.x Package Migration (REMOVED CAPABILITY)

IM 7.2: Apache HttpClient 4.x — classes under org.apache.http.*.

IM 7.3.0: Apache HttpClient 5.x (transitive via Spring Boot 3.5) — classes under org.apache.hc.*. The old org.apache.http.* packages are no longer on the classpath.

Impact on customers: Customer Groovy classes (under src/main/resources/repo/classes/*.groovy) that import or use HttpClient 4.x will fail to compile/run on IM 7.3.0. This is one of the most common patterns in customer integration code — direct REST calls from Groovy processors typically use HttpClient.

Customer migration: not 1:1 — the new packages split between client5, core5, and classic sub-packages, and method signatures changed beyond imports. See the per-class mapping in §10 Apache HttpClient 4.x → 5.x. Highlights:

Also: method signatures changed. For example, response status access went from response.getStatusLine().getStatusCode() (4.x) to response.getCode() (5.x). Code review is required beyond just import rewriting.

The PFIMCORE-2957 upgrade script reports an advisory for any org.apache.http.* import — auto-rewriting is unsafe because the package split is not a uniform prefix swap and the API changes go beyond imports.

3.25 SnakeYAML 1.x → 2.x — Polymorphic YAML Loading Restricted (CHANGED DEFAULT)

IM 7.2: SnakeYAML 1.25 — new Yaml().load(input) allowed loading arbitrary Java classes from !!java.lang.… or !net.pricefx.… tags in YAML content.

IM 7.3.0: SnakeYAML 2.6 — SafeConstructor is the new default (CVE-2022-1471 hardening). Polymorphic loading throws ConstructorException unless explicitly opted in.

Impact on customers: Customer Groovy scripts that load YAML with new Yaml().load(...) against a generic Object and rely on polymorphic class instantiation will throw at runtime. Customer YAML files that contain !!java.lang.… or !net.pricefx.… explicit class tags will be rejected.

Customer migration:

• Use type-bounded loading: yaml.loadAs(MyClass.class, input) instead of yaml.load(input).

• If polymorphic loading is required, opt in explicitly: pass LoaderOptions.setAllowedTags(...) (or construct with a Constructor instance instead of the default SafeConstructor).

• Remove !!java.lang.… / !net.pricefx.… tags from customer YAML files unless they're on an explicit allowed-tag list.

The PFIMCORE-2957 upgrade script does not rewrite this — both the customer's Groovy and their YAML files need manual review. See §19D of the migration guide for the full SnakeYAML 1→2 API tightening notes.

3.26 Camel Removed Components (BREAKING — Deploy-Time Failure)

IM 7.3.0 ships Camel 4.18 which removed several components. Customer routes whose URIs reference these components will fail at deploy time with a "no component found" error.

Customer migration: remove the URI from routes and migrate to a supported component (e.g., switch FB/HDFS integrations to direct HTTP / file integrations). No 1:1 replacement.

The PFIMCORE-2957 upgrade script reports an advisory for any route URI referencing these components. See §6.11 of the migration guide for the full removal timeline.

3.27 Camel Template / Script Component Security (BREAKING — Silent Breaker)

Camel 4.13 changed the default: most template (velocity, freemarker, mustache, mvel, string-template, chunk, jolt, xslt, xslt-saxon) and language/script (language, groovy, mvel, python, js) components no longer accept header-driven template content unless the endpoint opts in via ?allowTemplateFromHeader=true.

Impact on customers: routes that rely on a header (CamelTemplateBody, CamelTemplateResource, CamelLanguageScript, or any custom header) to dynamically feed template / script content will silently fall back to the configured static content. The route does not throw — it just produces the wrong output. This is a silent breaker; customers won't see an error.

Customer migration: review every URI using a template / script component and add ?allowTemplateFromHeader=true where header-driven content is intentional.

See §6.13 of the migration guide for the full component list and the security rationale.

3.28 Apache POI 4.x → 5.x API Migration (BREAKING — API)

IM 7.3.0 uses Apache POI 5.5.1 (was 4.1.2 in 7.2). Multiple breaking API changes affect any customer Groovy that reads or writes Excel.

Key changes:

• Cell.CELL_TYPE_* integer constants removed — use the CellType enum (CellType.STRING, CellType.NUMERIC, etc.) instead.

• Cell.setCellType() removed — use setCellValue(...) or other specific setters.

• CellStyle.ALIGN_CENTER → HorizontalAlignment.CENTER; CellStyle.SOLID_FOREGROUND → FillPatternType.SOLID_FOREGROUND; similar enum-replaces-constant pattern across alignment / fill / border.

• OLE2NotOfficeXmlFileException relocated — try-catch patterns for XLS vs XLSX detection break; use FileMagic class instead.

• new XSSFWorkbook(input) closes the input stream on failure in 5.x — fallback to HSSFWorkbook(input) after failure is no longer possible. Use FileMagic for upfront format detection.

• Streaming reader (monitorjbl-xlsx) package relocated: com.monitorjbl.xlsx.StreamingReader → com.github.pjfanning.xlsx.StreamingReader (monitorjbl is abandoned; pjfanning is the maintained fork).

• poi-ooxml-schemas renamed to poi-ooxml-lite / poi-ooxml-full — pom dependency update for customers running their own build.

Customer migration: manual rewrite — the API changes are too broad for a 1:1 regex replacement. The PFIMCORE-2957 upgrade script does not auto-rewrite POI usage. See §22 of the migration guide for the full breaking-change list and the format-detection pattern change.

3.29 Camel Health Check Changes (CHANGED DEFAULT)

Several health-check defaults flipped in Camel 4.x:

• /q/* paths → /observe/* (Camel 4.14) — customers monitoring /q/health, /q/metrics will get 404s unless paths are updated.

• Routes with autoStartup="false" report UP (Camel 4.7) — previously reported DOWN; monitoring dashboards may show misleading green status.

• SupervisingRouteController UnhealthyOnExhausted / UnhealthyOnRestarting default to true (Camel 4.7) — affects customers using SupervisingRouteController for resilient route management.

• FTP producer health checks added (Camel 4.17) — a transient FTP failure may report the route as DOWN and trigger pod restart. Set camel.health.producersEnabled=false to opt out.

Customer migration: update monitoring tools / dashboards for the /observe/* paths; review health-check expectations for autoStartup=false routes; opt out of FTP producer health checks if false-DOWNs cascade into pod restarts.

See §6.7 of the migration guide for the full health-check change list.

3.30 Camel Exchange API Changes (CHANGED API)

Several Camel Exchange constants and methods changed in 4.x. These affect customer Groovy code (in repo/classes/) and inline <groovy> blocks in routes:

Customer migration: manual review of customer Groovy code and inline <groovy> in routes against the table. The PFIMCORE-2957 upgrade script auto-rewrites only Exchange.ACTIVE_SPAN; the rest are advisories.

See §6.8 of the migration guide for the full Exchange API change list.

3.31 Camel REST DSL Defaults Changed (CHANGED DEFAULT)

Customer REST routes are affected by several Camel 4.5+ default flips:

• inlineRoutes defaults to true (Camel 4.5) — REST routes are inlined into a single Camel context. May affect route lookup by name.

• useXForwardHeaders defaults to false (Camel 4.5) — customer REST endpoints behind a reverse proxy may stop honoring X-Forwarded-For / X-Forwarded-Proto; must opt in explicitly.

• Swagger 2.0 support removed; only OpenAPI v3 (Camel 4.5) — customer integrations consuming Swagger 2.0 spec must switch to OpenAPI v3.

• OpenAPI spec generated once at startup (Camel 4.5) — customers fetching /openapi.json no longer see runtime changes per request.

• Property placeholders in REST DSL resolved eagerly (Camel 4.5) — {{prop}} substitution happens at endpoint build, not per request.

• swagger-request-validator removed (Camel 4.6) — validator no longer checks for missing required JSON nodes.

• Contract-first uses individual routers per endpoint (Camel 4.18) — affects customers using contract-first REST.

Customer migration: review REST DSL routes against this list. Set useXForwardHeaders=true if behind a proxy; switch Swagger 2.0 consumers to OpenAPI v3.

See §6.10 of the migration guide for the full REST DSL change list.

3.32 AWS SDK Multipart / Presigned URL Changes (CHANGED API)

The AWS SDK was bumped from 2.15.50 to 2.42.13 (IM-managed). Customer Groovy code that uses the AWS SDK directly should be aware of:

• Multipart upload (SDK 2.30.0+): ContentStreamProvider::newStream() is called twice during multipart upload. Customer code that assumed a single call (e.g. a stateful or single-use stream provider) will break.

• Multipart PUT (SDK 2.30.1+): explicit contentLength in multipart PUT via transfer manager throws content-length errors.

• Presigned URLs (SDK 2.21.16+): presigned URL signature changed when endpointOverride + HTTP (not HTTPS) is used — known to break MinIO setups.

• General S3 client improvements (chunked upload, multipart) — usually a non-breaking improvement, but verify any custom S3 code.

Customer migration: review any direct AWS SDK usage in customer Groovy for the patterns above. Manual rewrite — no auto-fix available. See §32 of the migration guide.

3.33 Camel Deprecated Components (DEPRECATED — Work in 7.3.0, May Be Removed Later)

These components still work in IM 7.3.0 but Camel has marked them deprecated; plan migration:

Customer migration: routes work today but should be migrated proactively before the components are removed in a future Camel release. The PFIMCORE-2957 upgrade script reports an advisory for any route URI / element referencing these components. See §6.12 of the migration guide.

3.34 Logback Configuration Restructured (CHANGED CONFIG)

IM 7.3.0 restructures logback-spring.xml: the previous 6-line shell-include format was rewritten to a ~109-line inlined configuration with conditional blocks for cloud-logging / logstash / debug. New <contextListener> for audit prop listener, <springProperty> bindings for LOGSTASH_ENABLED, CLOUD_LOGGING, LOGBACK_DEBUG. Conditional <if> blocks require the janino dependency (added).

Impact on customers: customers who have overridden the IM logback config with custom appenders, log levels, or filter rules need to re-base their overrides on the new structure. Customers who use the default IM logging behavior are unaffected.

Customer migration: if your IM has a custom logback.xml override, diff against the new IM 7.3.0 default and re-apply your customizations. See §36 of the migration guide.