How to use logback-classic inside plugin? Conflicts with clion jar containing log4j binding Follow
In my plugin I need to output logging messages with line number, time and so on. So for that purpose I need some logging framework which output I would redirect to ui.
So I tried using logback-classic and providing custom appender, that would output messages to ui. To ininitialize the appender in my plugin I cast Logger returned from slf4j to logback-classic. But slf4j can be bound only to one logging framework at a time and when I run plugin, slf4j binds to log4j from clion jar.
I tried to exclude the log4j from the classpath but that didn't work. I also tried to use log4j that clion uses instead of logback-classic, but I was unable to get log4j logger because it is deprecated.
Can I use some slf4j logging framework (like logback-classic) inside of a plugin? Or can I somehow remove log4j binding from the classpath?
Please sign in to leave a comment.
Here are the conflicts with log4j binding:
Here is the code where I cast slf4j logger to logback-classic logger and because the log4j binding is used, the error is raised here:
Can you please share the dependencies section in your Gradle build script?
Yes, of course
Why don't you simply use slf4j in your plugin, without specifying any implementation? This will use the implementation provided by CLion, which is log4j in CLion 2021.3 and java.util.logging in CLion 2022.1.
The logger output is redirected to ui by Appender, so I need to access the Appender directly to specify ui component. For that I cast slf4j logger to concrete implementation of logback-classic, and then I grab appender and specify ui component (I added the code earlier in comments)
If you need to display logs coming from your code in your UI, the best solution is to implement an entirely separate mini-logging framework, not depending on SLF4J or anything else, and use that to keep track of your logs. Your framework can also forward logs to the SLF4J logger if you need to write your logs to idea.log too.
Any solution relying on casting a logger instance to a specific implementation class is very likely to break in CLion 2022.1, which will switch from log4j to java.util.logging.
I'll think about implementing a separate logging. I was wondering may be I could use java.util.logging or something like tinylog, which does not depend on SLF4J, is it reasonable idea? Or something can break?
Tinylog should work, yes.