We have some code for making migrations simpler. I wonder if perhaps we can make a system that maps log4j 1 plugin classes and attributes into their equivalent 2.x plugins. Not necessarily as classes but as some sort of config file that can be extended to form compatibility mappings. Then we should be able to easily read a v1 config file and still use v2 plugins.
Alternatively, we could try to add metadata to the v2/v3 plugins that indicate what their old v1 equivalent would've been where applicable. I have some ideas around plugin metadata that I'd like to explore that I hope to try working on this weekend. I had an unrelated idea on how to show a GUI for configuring various appenders/layouts/etc. in a Jenkins plugin, and if I had access to a standard plugin metadata API, I'd be able to potentially generate all sorts of configuration UIs automatically. This should hopefully be useful for mapping different configuration formats to the same internal model or object graph. On Thu, 29 Aug 2019 at 15:43, Gary Gregory <[email protected]> wrote: > > At work we have one main hurdle to update one our projects from Log4j 1 to > 2: How do we migrate installed applications from Log4j1 configurations to > Log4j2. > > I started to work on this a long time ago but only got the basics working > which is in Log4j2 now: The idea is to read a Log4j1 config file as is and > map it to Log4j2. If you do not use a Log4j1 (or Log4j1 "extras") > appenders, all bets are off obviously. > > Gary > > On Thu, Aug 29, 2019 at 3:38 PM Matt Sicker <[email protected]> wrote: > > > At first I was concerned because on the log4j2 GitHub repo page, it > > had less than 1000 dependent users, though it turns out that stat is > > for the log4j2 parent pom, not the library. Anyways, some stats: > > > > * log4j-api about 51k: > > > > https://github.com/apache/logging-log4j2/network/dependents?package_id=UGFja2FnZS0xODAwMzE0MTQ%3D > > * log4j-core about 69k: > > > > https://github.com/apache/logging-log4j2/network/dependents?package_id=UGFja2FnZS0xODAwNzg2NjI%3D > > > > Not bad, right? But then we check some other stats: > > > > * log4j 1.x about 298k (!): > > > > https://github.com/apache/log4j/network/dependents?package_id=UGFja2FnZS0xNzk4NzY0ODE%3D > > * commons-logging about 95k: > > > > https://github.com/apache/commons-logging/network/dependents?package_id=UGFja2FnZS0xNzk5MTUzNzU%3D > > * slf4j-api about 319k (!!): > > > > https://github.com/qos-ch/slf4j/network/dependents?package_id=UGFja2FnZS0xNzk3Nzg3MDg%3D > > * logback-core about 61k: > > > > https://github.com/qos-ch/logback/network/dependents?package_id=UGFja2FnZS0xNzk5MzMyMDg%3D > > * logback-classic about 148k: > > > > https://github.com/qos-ch/logback/network/dependents?package_id=UGFja2FnZS0xNzk5MzMyNDM%3D > > > > It seems like we have room to grow marketing-wise. What do you all > > think we can do to improve that? I think trying to get some of the > > zillions of 1.x users to upgrade already would be cool. Do note that > > these stats include tons of throwaway projects, but it seems as though > > that could even be influenced. How many setup guides for various > > Java/Scala/Kotlin/Groovy frameworks default to recommending logback or > > even log4j 1.x? Or projects that try to use java.util.logging and > > suffer for it (like Jenkins hehe)? > > > > -- > > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
