Class DiagnosticRenderer

  • All Implemented Interfaces:
    ReportRenderer<DiagnosticConfig>

    public class DiagnosticRenderer
    extends java.lang.Object
    implements ReportRenderer<DiagnosticConfig>
    Render configuration diagnostic info.

    Commands rendered in registration order. All commands are rendered with SCAN marker to indicate classpath scanning. Environment commands are also marked with GUICE_ENABLED to indicate that only these commands may use guice injections.

    Bundles rendered as tree to indicate transitive installations. Dropwizard and guicey bundles are rendered together: first dropwizard bundles (because they actually register first) and then guicey. Possible markers:

    • LOOKUP when bundle come from lookup mechanism
    • DW when bundle is dropwizard bundles

    Installers are rendered in execution order. Extensions (if enabled) are rendered relative to used installer. Not used and disabled installers could be rendered too. If installer resolved by classpath scan then SCAN marker shown.

    Installer report could contain installer interface markers in order to indicate installer abilities:

    • TYPE - install extension by type
    • OBJECT - install extension by instance
    • BIND - creates custom guicey bindings
    • JERSEY - applies custom jersey configuration
    • OPTIONS - supports options

    If extensions print enabled without installers enabled then all extensions are rendered in registration order. Markers:

    • HOOK when extension installed by GuiceyConfigurationHook
    • SCAN when extension found by classpath scan
    • LAZY when LazyBinding annotation set
    • BINDING when extension detected in manual guice bindings (possibly not only there)
    • JERSEY when extension managed by jersey (annotated with JerseyManaged)
    • OPTIONAL when extension is registered as optional

    Guice modules are rendered by type in registration order. OVERRIDE marker may appear if module was registered as overriding.

    When item registered multiple times marker REG(N/M) shown where N - accepted registrations count and M - overall registrations count. For class based registarions it would always be REG(1/M). For instance registrations any items count could be accepted (according to deduplication logic).

    Since:
    22.06.2016
    See Also:
    for diagnostic data source