On 19.08.25 09:31, Per Nyfelt wrote:
[...]
1. Set the log level on the root logger
@Grab(group='org.apache.logging.log4j', module='log4j-api',
version='2.20.0'),
@Grab(group='org.apache.logging.log4j', module='log4j-core',
version='2.20.0'),
@Grab(group='org.apache.logging.log4j', module='log4j-slf4j-impl',
version='2.20.0')
import org.apache.logging.log4j.Logger
import org.apache.logging.log4j.LogManager
import org.apache.logging.log4j.Level
import org.apache.logging.log4j.core.config.Configurator
Configurator.setRootLevel(Level.INFO)
@Field
final Logger log = LogManager.getLogger()
In this case only LogManager.getLogger() works,
LogManager.getLogger(this.class) does not work.
not the reverse? getLogger should have the problem,
getLogger(this.class) maybe not. That is also what I can verify.
[...]
I.e. IndyInterface instead of my script class.
yeah, we have at least one bug in the indy callsite caching code, that
is causing this. Would be nice if LOG4j had a way to ignore classes in
that discovery phase... it does not, right?
To make log output better you need to do (the script name is
createExcel.groovy)
@Field
final Logger log = LogManager.getLogger(this.class.name
<http://this.class.name>)
Configurator.setLevel(log.getName(), Level.INFO)
Configurator.setRootLevel(Level.INFO)
LogManager.getContext(false).updateLoggers()
09:24:29.625 [main] INFO createExcel - Found 2 CSV files to process.
LogManager.getLogger(this.class) does NOT work (results in no output) which is
curious.
In my test it was for example Script1 if executed from a GroovyShell, or
the script name as class name if executed from the command line.
bye Jochen
