> So you are saying that you would simply add a log4j1 to log4j2 bridge > right. And those libraries that use the old version then automatically use > the bridge. And everything runs agains the new version then regardless. >
yep. they designed it to do that, and it works as advertised. I used to bridge j.u.l and JCL to slf4j feeding log4j1, and now am doing it with JUL, JCL, and slf4j feeding log4j2. > > I believe slf4j is also meant for that right? I don't like its deployment > but it's super easy of course. So you would bridge log4j1 to log4j2 for > example (for older libraries/systems) and meanwhile you write your own code > against slf4j so that it is portable to another framework if required. > precisely. that's why I use the slf4j bindings in my own stuff. > > I would personally still be tempted to move to log4j2 if it's a better > product. But mostly I believe the Java progression version requirement is > what would hold me back. Java 1.6 is probably not so bad. Knowing that if I > jumped to log4j2 I would need to be very conservative and not jump on the > 1.7 and 1.8 bandwagon, would ... reduce the attractiveness of the upgrade. > From my perception (and I must say I am *very* perceptive, people regularly > tell me if I get the chance, how right on the mark I am) the biggest > benefit of log4j2 from an upgrade perspective is to be right where the > money is. The biggest downside is higher java version requirements. I don't > think (If I am allowed to voice a sentiment that may not be warranted here) > the new API thing is absolute perfection but that would not hold me back, > because progress is possible and progress is what happens in the future, > not the past. > I hadn't been keeping track of the Java version dependencies, and I agree that future versions depending on Java 7 will probably cause some people not to switch. But as observed, log4j2 2.3 is available. how big of an issue is a Java 7 dependency? One problem is having an environment that absolutely cannot be upgraded (some web environments and old OSes come to mind), but how big is that space? I can't recall any old code I've seen that won't run on a newer JVM that it was designed for. -- *NOTICE: Whirlpool Corporation e-mail is for the designated recipient only and may contain proprietary or otherwise confidential information. If you have received this e-mail in error, please notify the sender immediately and delete the original. Any other use or disclosure of the e-mail by you is unauthorized.*