Expand description
Application bootstrap: config loading, logging, and the Axum server.
Re-exports axum so generated Larust applications don’t need to depend
on it directly for router/type access. tokio cannot be re-exported the
same way because #[tokio::main]’s macro expansion requires tokio to
be a directly resolvable crate name at the call site.
Re-exports§
pub use axum;
Structs§
- AppPaths
- Canonical locations belonging to one Larust application.
- AppState
- Explicit, clonable application state for code that should not depend on Larust’s legacy process-wide helper facades.
- Application
- Config
- Error
Pages - Rendered once (at
Application::with_error_pagescall time, not per request) and cached as plainStrings rather than a render closure or alarust_view::View- these pages have no per-request dynamic content (no session, no user), and this crate has no dependency on the view engine at all (seeCargo.toml), so there’s nothing a closure would buy over pre-rendering once. - Graceful
Shutdown - Configuration for
crate::Application::with_graceful_shutdown- opt-in: anApplicationthat never calls that method keeps today’s exact behavior (a bareaxum::servethat exits the instant Ctrl+C is pressed). Flipping every existing app’s shutdown behavior silently would be exactly the kind of surprise a framework upgrade shouldn’t introduce.
Enums§
- AppError
- The framework’s primary error type.
Functions§
- config
- Returns the process-wide config
Application::new()already loaded - the sameOnceLock-backed idiomlarust_orm::pool()uses for the connection pool. Unlikepool(), this panics rather than returning aResultif called beforeApplication::new(): every Larust entry point callsApplication::new()as its first line (there’s no analogue topool()’s “forgot to callconnect()later” scenario - nothing beforeApplication::new()could plausibly need config at all), so treating this as a real caller-contract violation (likeabort()’s own documented panic for an invalid status code) rather than aResultevery call site would need to unwrap anyway is the better fit here. - default_
internal_ html - The framework’s own built-in 500 page. Production-mode only - debug
mode (
APP_DEBUG=true) never reaches this; seeerror::debug_page. - default_
not_ found_ html - The framework’s own built-in 404 page - styled to match the demo app’s
branding (see
page_shell’s own doc comment for the exact source of the color tokens/copy this mirrors). - resolve_
app_ root - Overrides the compile-time-baked app root a generated app’s own
paths()function would otherwise always use unconditionally (env!("CARGO_MANIFEST_DIR"), fixed atcargo buildtime to wherever the build happened to run) - the identicalxr upgrade/LARUST_CHECKOUT_ROOTpattern (see that command’s ownresolve_checkout_root), applied here for the same reason: “baked in” doesn’t survive every real scenario. Without this, a binary built on one machine (a CI runner, a dev box) and then copied to a different directory on whatever actually serves it - rather than built in place there, the wayxr deploydoes it today - would still look for.env/storage//database/at the build machine’s own path, not wherever it actually ended up. SetLARUST_APP_ROOTas a real process environment variable (e.g. a systemd unit’s ownEnvironment=LARUST_APP_ROOT=...line) to unlock exactly that - a minimal deployment needing nothing but the compiled binary and an.envfile sitting next to wherever it’s actually run from. - try_
config config()’s non-panicking twin, for the rare caller that has a sensible fallback behavior for “noApplication::new()has run yet” rather than treating it as a contract violation - e.g.larust_http::session’s cookie-name derivation, which needs to behave identically whether or not the specific test harness building a router happened to construct anApplicationfirst.- try_
paths - Returns the process-wide paths
Application::new()already published -Noneif noApplicationhas been constructed yet in this process (every narrow test harness that builds a session-bearing router directly off a bare pool, with noApplication::new()call anywhere in the test, hits this case - seelarust_http::session::session_layer’s own doc comment for why that’s handled gracefully rather than treated as a contract violation, the identical shapetry_config()already has).