ontodev
Running robot commands from another JVM program changes log4j root logger level
With the root logger set to INFO When run any command from robot-command, the root logger after that command is set to ERROR.
I'm trying to dig into where this could happen (maybe a third party lib?)
Thats in here: https://github.com/ontodev/robot/blob/master/robot-command/src/main/java/org/obolibrary/robot/CommandLineHelper.java#L940-L951
I'm calling robot commands directly from my code, maybe I should avoid doing that…
Thanks @bjonnh. I find Java logging completely baffling, so I don't have the first idea how to fix this. Is there something that ROBOT should be doing differently?
I don't know really. The thing is I'm not sure if you designed robot-command to be used as a library or not. For a main application, it make sense to play with the root logger, for a library it should not. So maybe there is a way to tell it "if you run in application mode, you can touch the logging". To be fair I'm not certain how to do that. Maybe a Singleton somewhere in the code that you can set to true when in application mode?
For now, I'm resetting the root logger levels after every of my robot calls. That works for me.
Sorry that I lost track of this.
robot-core is designed to be used as a library, but robot-command is designed as a CLI. The library code always throws exceptions and should not mess with the logger. The command code sometimes exits instead of throwing, and messes with the logger (as you point out). The code you're pointing to is under robot-command.
For an application written in Java (or whatever JVM language) I would expect you to only be using robot-core stuff, or maybe some of the robot-command utilities, but not calling the various robot-command execute() methods.
Is there something you need to do that isn't being covered by the library operations in robot-core?
Not really, I was just using the robot commands by convenience so I will probably use robot-core instead. Do you have any rules in term of stability of the core API over time?.
For the story, I'm using that in a toy-build system I made to build ontologies with a DSL such as: https://github.com/bjonnh/konbu/blob/master/konbu.kts
I'm a zealot about stability of the robot-core API. :smile: We run japicmp as part of our continuous integration tests to ensure that we don't break signatures, we have an extensive integration test suite to catch regressions, and overall I'm very strict about backwards compatibility of all changes.
Regarding konbu, we've talked about a number of alternatives to Make here, but none has ever gained traction. Here are some discussions that might be of interest: #37, #149, #513, #652. Happy to talk more about it some time.