Project.logger vs. logger. Why are these different implementations?


(Tim Roes) #1

Is there a reason ‘project.logger’ returns a ‘org.gradle.api.logging.Logging$LoggerImpl’ whereas ‘logger’ in a build script returns a ‘ch.qos.logback.classic.Logger’?

The later one doesn’t accept GStringImpl as parameter and so you often need to fetch the project.logger instead of just using ‘logger’. Is this a design decision, and if so, what is the reason for that decision?


(René Groeschke) #2

logger and project.logger should both be org.gradle.api.logging.Logging$LoggerImpl. Do you have a selfcontained example?

When I ran the following:

println logger.getClass()
println project.logger.getClass()

both println statements return org.gradle.api.logging.Logging$LoggerImpl


(Tim Roes) #3

Since I thought I will was following this thread and I wasn’t my very late reply now:

I already forgot what exactly I was doing that time and tried to remember what I tried that day. So I ended up with the following again:

‘’’ gradle.taskGraph.with {

println logger.getClass()

println project.logger.getClass() } ‘’’

I guess it was, what I tried and didn’t think about it that time, because looking at it now, I would assume, that logger of course access taskGraph’s internal logger variable (due to the lack of private variables) instead of the project one.