Migrate away from deprecated ResultObject API

[cuioss-oliver]

Background

ResultObject is @Deprecated(since="2.0", forRemoval=false) from cui-core-ui-model:2.4.0. The related types ResultDetail and ResultState are not deprecated. The suggested replacement for HTTP use cases is HttpResult from cui-http.

SonarQube flags this as S1874 (deprecated API usage). Rather than suppressing the warnings, we keep them visible in Sonar and track the migration here.

Affected Files (14)

Production code

• DisplayNameMessageProducer.java — uses ResultObject in message resolution
• ResultObjectBackingBean.java — backing bean wrapping ResultObject
• ResultContent.java — content model based on ResultObject
• LazyLoadingThreadModel.java — interface returning ResultObject
• ErrorController.java — error handling with ResultObject
• ResultErrorHandler.java — error handler consuming ResultObject
• resultObject.xhtml — Facelets template for ResultObject display

Package-info / metadata

• 3 package-info.java files referencing ResultObject in Javadoc

Test code

• DisplayNameMessageProducerTest.java
• ResultContentTest.java
• CoreJsfTestConfiguration.java
• TestConceptKey.java (bootstrap module)

Migration Variants

Variant A: Local OperationResult interface (recommended)

Introduce a new local interface (e.g. OperationResult<T>) in cui-jsf-api that captures the same semantics:

• Wraps result state (ResultState), detail messages (ResultDetail), and the result value
• Provide an adapter/factory at the JSF boundary to convert from ResultObject where external APIs still return it
• Internal APIs use only the new type — clean break from deprecated dependency

Pros: Clean internal APIs, no deprecated types in signatures, can evolve independently
Cons: More upfront work, adapter boilerplate at boundaries

Variant B: Direct HttpResult migration

Replace ResultObject usage with HttpResult from cui-http:

• Only suitable if all use cases are HTTP-based (they are not — LazyLoadingThreadModel and ResultContent are generic)
• Would require adding cui-http as a dependency to cui-jsf-api

Pros: Reuses existing maintained type
Cons: Wrong abstraction level for non-HTTP use cases, adds heavyweight dependency

Variant C: Accept deprecation (lowest effort)

forRemoval=false means ResultObject will remain available indefinitely. Keep using it and accept the Sonar warnings:

• No code changes needed
• Sonar S1874 issues stay open as accepted technical debt

Pros: Zero effort
Cons: Permanent Sonar noise, couples to deprecated API

Decision

To be discussed. Variant A seems most appropriate given the mixed HTTP/non-HTTP usage.