Exposed Ktor Core
Latest stable Based on Exposed release 2.0.0
Backend-neutral Ktor health, readiness, error, and metric contracts for the selective Exposed artifacts.
Problem
Section titled “Problem”The legacy Ktor artifact coupled JDBC, R2DBC, and cache APIs. This core module keeps route and error contracts independent of those backends.
When to use it
Section titled “When to use it”Use it when an application needs health routes and readiness probes without adding a database adapter. Choose a child adapter only for the backend it actually uses.
Coordinates
Section titled “Coordinates”implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<version>"))implementation("io.github.bluetape4k.exposed:bluetape4k-exposed-ktor-core")Core concepts
Section titled “Core concepts”ExposedKtorReadinessProbe is caller-owned and cooperative. Registration snapshots validated component names and backend tags. Readiness executes probes sequentially under one monotonic deadline.
Quick start
Section titled “Quick start”Register one or more cooperative probes and install the routes in the application’s existing routing tree:
route.bluetape4kExposedHealthRoutes(probes = listOf(probe))API by task
Section titled “API by task”- Implement
ExposedKtorCooperativeReadinessProbefor an application-owned probe. - Call
Route.bluetape4kExposedHealthRoutesfor liveness and readiness. - Compose
bluetape4kExposedCoreErrors()inside the application’sStatusPagesblock.
Recommended patterns
Section titled “Recommended patterns”Keep probes small, cancellation-cooperative, and free of resource ownership. Use stable low-cardinality component names and inject the application MeterRegistry.
Integrations
Section titled “Integrations”Use bluetape4k-exposed-ktor-jdbc, bluetape4k-exposed-ktor-r2dbc,
bluetape4k-exposed-ktor-cache, or the tenant-specific JDBC/R2DBC adapters
alongside this module. The core module does not create dispatchers, pools,
databases, scopes, or routes outside the paths requested by the caller.
Configuration
Section titled “Configuration”Probe registration requires one to sixteen unique component names matching [a-z][a-z0-9_.-]{0,62}. Paths are literal absolute paths and the finite readiness timeout is positive.
Failure modes
Section titled “Failure modes”An invalid registration fails before routes are installed. A probe exception becomes DOWN; an expired shared deadline becomes TIMEOUT; caller cancellation is rethrown. Error responses use fixed messages and do not expose paths or causes.
Operations
Section titled “Operations”Readiness is sequential with at most one probe in flight. Metrics use fixed backend, operation, component, and outcome tags. The application owns authentication, rate limiting, telemetry export, and shutdown.
Testing
Section titled “Testing”Test route registration, deadline expiry, cancellation, error redaction, duplicate components, and meter-family collisions with deterministic cooperative probe fakes.
Workshops
Section titled “Workshops”The selective Ktor modules are published in the 2.0.0 release line; no workshop artifact is published yet.
Limitations
Section titled “Limitations”The core module does not perform backend I/O and cannot make a non-cooperative or blocking probe safe. JDBC and R2DBC behavior belongs to their respective adapters.