Aller au contenu

Configuration dynors-logging — librairie vs applications

dynors-logging (com.dynors:dynors-logging) est une bibliothèque : abstraction LoggingProvider, bean DynorsLogger. Chaque application choisit le provider (console, sentry, noop, …) et les secrets (DSN Sentry, etc.) dans application.yml et l’environnement.

!!! note "Source et tutoriel" Contenu aligné sur le dépôt agrégé dynors : docs/CONFIGURATION_DYNORS_LOGGING.md.
Exemples de code, pratiques dev/prod : page Logging centralisé (même chapitre MkDocs).

SLY (SelebeYone) et applications tierces

  • dynors-logging n’utilise pas SLY : envoi vers Sentry / console selon le provider. App tierce : DSN et environment propres au client ; noop / console possibles sans alignement sur dynors.interapp.* — voir CONFIGURATION_DYNORS_LOGGING.md.

1. Rôles

Couche Responsabilité
dynors-logging LoggingProvider, implémentations (console, Sentry, noop), DynorsLogger.
Chaque application dynors.logging.provider, DSN et options par env ; complète souvent SLF4J/Logback pour les logs standards.

2. Propriétés principales (dynors.logging.*)

Clé Rôle
dynors.logging.provider console (souvent défaut si non renseigné — voir module) · sentry · noop · (futur datadog, etc.).

Exemple Sentry :

dynors:
  logging:
    provider: sentry
    sentry:
      dsn: ${SENTRY_DSN:}
      environment: ${ENVIRONMENT:production}

Le provider Sentry peut aussi lire SENTRY_DSN depuis l’environnement — vérifier la javadoc du provider dans dynors-extensions.

Secrets : DSN et clés via env / Vault, pas dans Git. GITLAB_TOKEN sert uniquement au registry Maven.

3. Références code

Élément Lien
README module packages/extensions/logging/README.md

Dernière mise à jour : 2026-04-12.