GeezerVison

Adds deployment environments (e.g. production, staging) to events. They're sent as the root environment property, matching the .NET (#371) and JavaScript (#193) clients and the server (Exceptionless #2570).

Self-hosted: upgrade the server first. Older servers drop the property.

Usage

Exceptionless.startup(config -> config.apiKey("YOUR_API_KEY").environment("production"));
Exceptionless.createLog("Deployment complete").setEnvironment("staging").submit(); // per-event override

Which value wins

flowchart TD
    A["EventBuilder.setEnvironment(name)"] -->|null| B[Value already on the event]
    A -->|valid| V[Use it]
    A -->|invalid| U[Send unspecified]
    B -->|none| C["config.environment(...) in code"]
    C -->|not set| D["exceptionless.properties → EXCEPTIONLESS_ENVIRONMENT<br/>→ system property → Spring property"]
    D -->|not set| E[Spring: the single active profile]

• Strict names: trimmed, casing kept, then it must match ^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$. Anything else (Staging West, prod/eu, produção, empty, over 64 characters) is unspecified and never rewritten.
• A configured value that's invalid stays configured and blocks the lower levels, the same as .NET.
• data.@environment (machine info) is untouched.
• The duplicate checker keeps the same error in different environments apart.

Testing

• Builds: ./mvnw verify on JDK 17, 21 and 25, plus Spring Boot 4, all green locally and in CI.
• Tests: 432 core tests plus the logging, servlet and starter modules.
• Mutation checks: each key rule was broken on purpose, and a test failed every time. The real-server end-to-end job was not run.

🤖 Generated with Claude Code