Upgrade to Log4j2 #51
Conversation
Only the workbench.Logger should be aware of the logging implementation used, all other classes should use the workbench.Logger class
…rent fallback for log4j1 + partial configuration for log4j2
…psulate the implementation Level + remove Log4j 1 Level from Logger public API + reverted most changes to the WorkbenchFrame class
…' into feature/upgrade-to-log4j2 # Conflicts: # src/com/vividsolutions/jump/workbench/Logger.java
…ll places where Log4j 1 should be removed
…hose in the log4j 1 xml file
# Conflicts: # src/com/vividsolutions/jump/workbench/Logger.java
|
Oh yeah, I forgot to mention, this PR will resolve #49 |
|
hey @Neutius thanks for this. first things first, just realized that this adds 1,5MB to overall OpenJUMP size? is that correct? if so, i'd draw a break here, because we are trying to keep small and having a 2MB sized logging solution is definitely overkill for simply logging to console and one file mainly :( would you be willing to explore the possibility of using a simpler, smaller logging solution? would have to research myself, but the 500kB of old log4j 1.x is probably a margin we can undercut easily. |
|
https://tinylog.org/v2/ sporting 180kB only looks like a contender |
|
@Neutius, did you see my evaluation wrt. to the size increase? how would you like to, if willing at all, to proceed? |
|
@edeso Sorry for my late response, didn't notice your first reaction. I can understand where you're coming from. The Log4j 2 jars are significantly bigger than their Log4j 1 counterparts, with lots of functionality we're not using. Having 20% of an application consist of unused third party code is annoying, to say the least. I'll discuss with my team how to proceed. We have experience migrating from Log4j 1 to Log4j 2, I'm not sure how much help we'll be migrating to a different logging framework. I'm also not sure how easy or hard it will be to migrate to a different logging framework, and whether or not the exact same behavior and configuration can be kept. This does make me wonder, how much unused functionality there is a logging framework, and how much work it would be to write the needed functionality? That would really reduce the size of the deployed application. Perhaps I'm underestimating, but it could be a viable option, right? |
thanks for being so understanding after putting in all the work!
t'd be great if you could spare the effort, if you can't we will simply postpone and do it at a later date
i'm pretty sure we will get close without to much jumping through hoops. after all these logging frameworks do a generally similar job
maybe. but having a maintained API that implements (our minimum reqs of the top of my head)
will allow us to concentrate on OJ instead. no need to reinvent wheels. question is only, which wheel to choose ;) |
I added and configured Log4j v2, and completely removed Log4j v1. As far as I've seen, the logging output is completely identical to before.
I partially rewrote the com.vividsolutions.jump.workbench.Logger class to use the new logging implementation, and slightly improved the code where I saw fit.
The API and functionality for comparing logging Level in Log4j2 is pretty weird and counter-intuitive. I did some debugging and testing to make sure I didn't mess up, see the screenshots below.
