926e06ef3c
This commit complete the migration to 'tracing' for all logging. Below
is a summary of all relevant commits, including this one:
Log improvements:
- All log (trace) messages are structured which means they contain fields
that can formatted by any subscriber.
- Logging can be disabled entirely by disabling the default `trace` feature.
- Routes and catchers now contain location (file/line) information.
- Two log format kinds: pretty and compact via ROCKET_LOG_FORMAT
- Coloring is not disabled globally. Thus applications can color even if
Rocket is configured not to.
- Rocket is more conservative about 'warn' and 'error' messages, reserving
those log levels for messages useful in production.
- Errors from guards logged by codegen now use the 'Display' implementation of
those errors when one exists.
- Secrets are never logged, even when directly asked for.
New features:
- Many Rocket types know how to trace themselves via a new `Trace` trait.
- `Either` types can now be used in `uri!()` calls.
- A `RequestIdLayer` tags all requests with a unique ID.
Breaking changes to configuration:
- `Config::log_level` is of type `Option<Level>`. `None` disables tracing.
- `log_level` now uses the traditional log level names: "off", "error",
"warn", "info", "debug", "trace", or 0-5. This replace the Rocket-specific
"normal", "debug", "critical".
- A new option, `log_format`, which is either `compact` or `pretty`,
determines how Rocket's tracing subscriber log trace messages.
Breaking changes:
- Hidden `rocket::Either` is now publicly available at `rocket::either::Either`.
- `rocket::Error` no longer panics when dropped.
- `main` generated by `#[launch]` returns an `ExitCode`.
- `FromParam` `Err` now always returns the actual error as opposed to the
string that failed to parse. To recover the original string, use `Either<T,
&str>`, where `T: FromParam`, as a parameter guard.
- Many types that implemented `Display` now instead implement `Trace`.
- `Error::pretty_print()` was removed. Use `Error::trace()` via `Trace` impl.
Internal improvements:
- Made more space in CI machines for tasks.
- Cleaned up testbench code using `inventory`.
Resolves #21.
|
||
|---|---|---|
| .. | ||
| chat | ||
| config | ||
| cookies | ||
| databases | ||
| error-handling | ||
| fairings | ||
| forms | ||
| hello | ||
| manual-routing | ||
| pastebin | ||
| responders | ||
| serialization | ||
| state | ||
| static-files | ||
| templating | ||
| testing | ||
| tls | ||
| todo | ||
| upgrade | ||
| Cargo.toml | ||
| README.md | ||
README.md
Rocket Examples
This directory contains projects showcasing Rocket's features.
Applications
-
A simple, API-only pastebin application, similar to https://paste.rs. Stores pastes locally on the file system. Implements a custom parameter guard,
PasteId, to parse and validate paste identifiers. -
A todo app with a web UI to add, delete, and mark/unmark items. Uses a SQLite database driven by diesel. Runs migrations automatically at start-up. Uses tera to render templates.
-
A real-time, multi-room chat application using Server-Sent Events (SSE) and JavaScript's
EventSource. Supports automatic reconnection with exponential backoff and live connection status.
Feature Examples
-
config- Illustrates how to extract values from a RocketFigment, how to store and retrieve an application specific configuration in managed state usingAdHoc::config(), and how to set configuration values inRocket.toml. -
cookies- Uses cookies to create a client-side message box. Uses private cookies for a session-based authentication. -
databases- Implements a CRUD-like "blog" JSON API backed by a SQLite database driven by each ofsqlx,diesel, andrusqlite. Runs migrations automatically for the former two drivers. Usescontribdatabase support for all drivers (rocket_db_poolsfor the first;rocket_sync_db_poolsfor the other latter two). -
error-handling- Exhibits the use of scoped catchers; contains commented out lines that will cause a launch-time error with code to custom-display the error. -
fairings- Exemplifies creating a customCounterfairing and usingAdHocfairings. -
forms- Showcases all of Rocket's form support features including multipart file uploads, ad-hoc validations, field renaming, and use of form context for staged forms. -
hello- Basic example of Rocket's core features: route declaration with path and query parameters, both simple and compound, mounting, launching, testing, and returning simple responses. Also showcases using UTF-8 in route declarations and responses. -
manual-routing- An example eschewing Rocket's codegen in favor of manual routing. This should be seen as last-ditch effort, much likeunsafein Rust, as manual routing also eschews many of Rocket's automatic web security guarantees. -
responders- Illustrates the use of many of Rocket's built-in responders:Stream,Redirect,File,NamedFile,contentfor manually setting Content-Types, andEither. In the process, showcases usingTempFilefor raw uploads. Also illustrates the creation of a custom, derivedResponder. -
serialization- Showcases JSON and MessagePack (de)serialization support by implementing a CRUD-like message API in JSON and a simply read/echo API in MessagePack. Showcases UUID parsing support. -
state- Illustrates the use of request-local state and managed state. Uses request-local state to cache "expensive" per-request operations. Uses managed state to implement a simple index hit counter. Also uses managed state to store, retrieve, and push/pop from a concurrent queue. -
static-files- UsesFileServerto serve static files. Also creates asecondmanual yet safe version. -
templating- Illustrates usingcontribtemplatessupport with identical examples for handlebars and tera. -
testing- Uses Rocket'slocallibraries to test an application. Showcases necessary use of theasyncClient. Note that all examples contains tests, themselves serving as examples for how to test Rocket applications. -
tls- Illustrates configuring TLS with a variety of key pair kinds. -
upgrade- Uses the connection upgrade API to implement WebSocket support using tungstenite.