Upgrade to Log4j2

[Neutius]

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.

[Neutius]

Oh yeah, I forgot to mention, this PR will resolve https://github.com/openjump-gis/openjump/issues/49

[edeso]

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.

[edeso]

https://tinylog.org/v2/ sporting 180kB only looks like a contender

[edeso]

@Neutius, did you see my evaluation wrt. to the size increase? how would you like to, if willing at all, to proceed?

[Neutius]

@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?

[edeso]

@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.

thanks for being so understanding after putting in all the work!

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.

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 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.

i'm pretty sure we will get close without to much jumping through hoops. after all these logging frameworks do a generally similar job

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?

maybe. but having a maintained API that implements (our minimum reqs of the top of my head)

• file and console appender
• configurable via config file (could go w/o, but having it is much more user friendly)
• supporting log levels
• configurable formatting of log entries (date/time/level etc.)

will allow us to concentrate on OJ instead. no need to reinvent wheels. question is only, which wheel to choose ;)