If you use the factory pattern for your configuration class (i.e. the 
configuration object is populated by the configuration file, and then, in 
run(), you call subConfig.buil() which returns a constructed configuration, 
maybe doing some computations pertaining to the configured thing), then you 
can do the logging in the build() method.
(that's what is done in the ServerFactory from dropwizard for example).

Or you could simply do the logging in the run() method if the factory 
pattern is too much :)
The run() method is executed not long after configuration is parsed. If 
your problem is happening inbetween, then maybe it makes sense to delegate 
the code that may fail to the SubConfig.build()? :)

Le vendredi 11 novembre 2016 09:25:30 UTC+1, [email protected] a écrit :
>
> Hi all,
>
> In my configuration I have a class that represents a part of the config. 
> E.g. (not really, but to make the point):
>
> subConfig:
>   propertyA: "b"
>
> Would become:
> class SubConfig {
>   public final String propertyA;
>   @JsonCreator
>   public SubConfig (@JsonProperty("propertyA") String propA) {
>     this.propertyA = propA;
>   }
> }
>
> Now my problem is that in the constructor of SubConfig I'd like to do some 
> logging. That does not show up in my logfile. I guess that's because the 
> loggers will be initialized after this (them needing the config 
> themselves). Is there a way around this? If anything fails in the config 
> class, the application won't start and no logging as to why is provided, 
> which is undesirable. Alternatively I can 'log' to System.out, but I don't 
> wanna.
>
> Groeten,
>
> Friso
>

-- 
You received this message because you are subscribed to the Google Groups 
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to