Reduce / configure log levels for the Tooling API

Old Forum Archive
1

First of all I want to thank you for the great work you have done with gradle.

At the moment i am trying to leverage the tooling api to execute embedded builds for a kind of of integration server. My problem is that the logoutput fills my console with messages like the following:

[Connection worker] DEBUG o.g.l.daemon.client.DaemonClient - Received object #332…

I have searched several hours for a hook to suppress this log messages or pipe them into a file.

Is there any possibility to configure/disable the logging of the DaemonClient or to redirect it into a file?

2

Hey,

It might be a bug. I expected to provide a configurable slf4j implementation and hence tweak the log levels but it didn’t have the effect it should have had.

Few questions, first: what version of tooling api do you use and what gradle target version do you connect to?

3

Thanks for your reply. I am currently using the tooling api provided with m7 to connect to a gradle instance of version m7. So both tooling api and gradle target version are m7.

4

Cool. I’ll do some digging and get back.

5

Thanks

6

Currently you cannot easily configure the log levels for the Tooling API.

The tooling API is divided into consumer piece (the tooling api jar) and the provider piece (basically the target gradle you connect to). The log levels for consumer you should be able to configure in slf4j regular way, e.g. use configurable implementation of slf4j (for example, log4j), prepare the configuration and make sure the configuration is consumed (for log4j that would be log4.properties somewhere on the classpath).

However, for the provider you cannot easily change the log levels at the moment. I’m creating a jira ticket for it and I’m pretty sure we want to fix it soon.

The only workaround that comes to my mind is wrapping your System.out with something that can filter out the tooling api debug entries. I know it’s not beautiful - we’ll fix this problem definitely. Thanks for reporting!

7

Thanks for your analysis. I am looking forward for the proposed fix and in the meantime I will add a filter to System.out as you suggested.

8

One more thing, the ‘received object’ statement and most others do come from the provider piece which means configuring slf4j will not reduce them.

Cheers!

9

That’s what I investigated too, since configuring logback as well as log4j didn’t show any effects.

10

The ticket attached to this says it is closed. Is there a resolution?

I am using the tooling API, redirecting standard error/output and passing -q as an argument, but the deamon is still logging to the console.

11

Just to add some more urgency to the request. People running tasks from withing STS-Gradle tooling are also affected. I looks like it is impossible to turn-off logging of stacktraces which is annoying to some.

See here: http://forum.springsource.org/showthread.php?136260-Gradle-Plugin-turn-off-stacktraces-for-failed-tests

I tried passing the “-q” option via STS. This seems to reduce logging (no more messages about ‘life cycle’ steps, but when the tests are failing it dumps very long / verbose stacktraces.

There doesn’t seem to be an option to disable stacktraces. There are only options to turn it on or make them ‘full’. According to the docs here http://www.gradle.org/docs/current/userguide/logging.html

Not putting any stacktrace related options should default to not printing them. This is indeed the behavior that I get when running via ./gradlew on the commandline but in the tooling API stacktraces seem turned on automatically.

Kris

12

I agree that it is annoying that exceptions thrown by failing taska are printed. Besides, it is pointless to print because the exception is also thrown by ‘BuildLauncher.run’. I currently workaround the issue by not printing anything written to stderr after I see the ‘"* Exception is:"’ line.

13

The stacktrace will be gone in Gradle 1.6. The tooling API will default to use the same logging options as the ‘gradle’ command does.