K-Int
We have completed the upgrade of six K-Int FOLIO backend modules to Grails 8 and JDK 25: Agreements, Licenses, Serials Management, Service Interaction, Interlibrary Loan and Open Access. Their shared Grails libraries have also been upgraded, including the Access Control integration where used.
For FOLIO implementors still running the Grails 6 generation, this is a useful moment to put module modernisation into the next upgrade plan. The benefit reaches beyond a newer framework: these distributions bring better visibility into the software you deploy, specific application repairs and evidence from exercising real upgrade operations.
A maintained foundation
Library applications have long lives. Their dependencies need continuing attention throughout those lives.
Apache’s support schedule lists Grails 6 as end of support, with community maintenance ending in June 2025. Commercial extended support may be available, but it is a separate arrangement. Grails 8 was released on 8 October 2026 and moves the framework onto the current Spring Boot 4.1 generation. We have qualified these modules on JDK 25.
That gives us a current foundation on which to maintain the applications and adopt subsequent fixes. It also makes the ongoing maintenance commitment explicit: Grails 8’s published maintenance schedule currently runs through July 2027. Keeping modules current is a continuing practice.
Know what is inside your deployment
Each of the six published backend images includes an attached SPDX Software Bill of Materials, or SBOM. This is a standard-format inventory of software components detected in the image.
Consider a newly disclosed vulnerability in a Java library. An implementor needs to establish whether their particular deployed build contains that library, which version it contains, and whether the affected operation is used. An SBOM helps answer the inventory questions without starting from a handwritten dependency list.
The images also carry SLSA-format build provenance records. Alongside the recorded image digest and publication receipts, these provide evidence for investigating how a particular artifact was built. Using a provenance format does not itself establish SLSA certification, and these build records are distinct from the signatures on Foundry’s distribution definitions.
We have checked the published registry records for all six images. These facilities were developed across the recent modernisation work; they are capabilities of our current distributions, rather than features supplied automatically by Grails 8.
Inventory is the starting point for security assessment. We also retain vulnerability assessments which examine affected library operations, application usage and deployment conditions. A scanner match needs that context; an assessment must be revisited when the code, dependencies or configuration change.
For operators, the practical gain is a more traceable route from an advisory to a decision about their deployment.
Improvements in the applications themselves
The migration also exposed issues worth fixing in the modules.
Grails 8’s compile-time query-safety check identified Agreements queries whose interpolated values had been flattened into ordinary strings. We repaired the affected builders and callers to use bound parameters for data values, retaining controlled construction for structural query elements. The compiler check remains enabled.
Additional regression tests exposed existing Agreements ingest defects involving transaction handling and a cached matching decision shared across tenants. The repairs preserve expected matching behaviour within the owning transaction and keep each tenant’s matching decision separate. These are concrete correctness improvements for the application, supported by focused regression tests.
We also replaced Agreements’ internal PushKB HTTP client with the Apache HTTP transport already present in its dependency family, removing its Micronaut dependency. Real HTTP tests exercise request bodies, responses and failure handling. The external PushKB service is unchanged.
Evidence for planning an upgrade
We upgraded and qualified the modules sequentially. Qualification included module tests and local application smoke checks, with module-specific exercises of populated tenant upgrades, stored content, restart behaviour, tenant isolation and recovery. For Agreements, we separately exercised the actual published image against populated data and checked that uploaded file bytes survived the transition.
That evidence gives implementors a useful starting point for their own rehearsal. Its boundary matters: the completed campaign tested Grails 7 to Grails 8 transitions. An installation on Grails 6 must establish the migration route from its exact module versions, including any intermediate upgrades and database prerequisites. The results do not establish a universal direct Grails 6-to-8 upgrade or an in-place downgrade procedure.
Inspect the published combination
All six upgraded backends and their compatible frontend selections are included in the published Foundry Snapshot distribution revision 72, folio-lsp-r72, as of 11 October 2026. Access Control is included through the consuming modules’ packaged dependencies.
You can inspect the FOLIO LSP distribution in Foundry Release Control. Its Distribution Revisions view lets you examine successive minted revisions, component versions and exact artifact identities, and download their descriptions. Select revision 72 to inspect the combination described here; the Snapshot channel can advance afterwards.
This is a published Snapshot distribution for evaluation. It is not an announcement of a stable FOLIO release or a claim that existing installations have already adopted it. Foundry’s signed release definitions make the selected combination verifiable; adopting the modules in FOLIO does not require adopting Foundry.
The current canonical K-Int module distributions use the Functional Source License, FSL-1.1-ALv2. Their separately managed Apache community editions have their own publication path. Implementors should check the licence and release status of the exact distribution they intend to adopt. Our stewardship discussion explains the wider direction.
For an implementor on Grails 6, the next step is to inventory the current module versions, agree the migration path with the module maintainers and hosting team, and rehearse it against representative data. These upgraded distributions give that work a current framework, inspectable artifacts and documented qualification evidence. We encourage implementors to make that evaluation part of their next release plan.