No easy way to disable logging of artifact resolution

[cheddar]

RepositorySystemSessionProvider always attaches

    session.setTransferListener(new ConsoleTransferListener());
    session.setRepositoryListener(new ConsoleRepositoryListener());

To the session. This fills the logs with a bunch of lines about resolutions, which is definitely nice to have in a development/debugging environment, but I'd rather not having it pollute my normal logs.

It would be awesome if it were easier for me to turn these off/plugin my own listeners/something that gives me control. It appears as if overriding the guice binding might be the easiest way to do this, but it's not clear how to override the repositories without having users adjust their settings.xml.

One option might be to make the Guice modules use a Guice Multibinder to inject a Set, then your default module could setup central like it's currently defaulting to and other users could use the Multibinder to add RemoteRepositories to the Set<>.

[cheddar]

Fwiw, this is what I'm currently doing to quiet down the listener:

https://github.com/metamx/druid/blob/guice/server/src/main/java/io/druid/server/initialization/Initialization.java#L138..L163

[jvanzyl]

I'll take a look tomorrow and make it pluggable.

[jvanzyl]

Would you be happier with SLF4J integration and you pick your implementation, or allow passing in the two transfer listeners? @electrum, you have an opinion?

[cheddar]

Slf4j at a minimum. Overriding the actual listeners seems like a generally
nice thing to allow for the long-term.

--Eric

On Tuesday, September 10, 2013, Jason van Zyl wrote:

Would you be happier with SLF4J integration and you pick your
implementation, or allow passing in the two transfer listeners? @electrumhttps://github.com/electrum,
you have an opinion?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-24206343
.

[electrum]

I agree that long term having the option to override the listeners is nice, but making the default ones log at debug level is fine for now.

This is probably controversial, but I think libraries should use JUL as that's part of the JDK and thus avoids any classloader or versioning issues. Applications using the library are of course free to bridge JUL into whatever backend they choose.