On Fri, Aug 14, 2015 at 5:27 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Gary, > > Do you have something in mind? While not hard, it is a fair amount of > work for an application to switch to a different logging API. Granted, it > is mostly just changing the call to get a Logger. But most applications > should also take advantage of the new parameter syntax as well. > I was thinking of something low key at first, especially if some of us know other committers on these projects: "Hi John, you might have seen that we've announced that log4j1 is EOL. Let us know if you'd like help or advice on porting to version 2. We understand that you might not be able to do so now or for a while, if at all. We have a porting FAQ here http://... and we'd appreciate any feedback and we provide support on our ML of course. If there are blockers for version 2 adoption, we'd like to know about them! Thank you and so on." > > What was your experience with projects upgrading to commons lang3 vs > commons lang? > Easy. All of the projects at work and FOSS were painless. It's a different kind of library of course. Aside from a couple of deprecated classes that were removed, migration was just a package name change. > I know quite a few people are still using commons httpclient vs the new > version, and that has been around a lot longer than Log4j 2. > For HttpComponents/HttpClient from 3 to 4, it's a little more tricky because of API deprecation and other changes I can't recall ATM. It required real work. Changes within r4 were a little easier. For the upcoming r5, I'm not sure. > What I really hope is that we stopped projects from switching from log4j 1 > to logback, although I am aware that many projects are using slf4j instead > and letting their customers choose. Frankly, if I hadn’t found limitations > (such as the ability to use Messages) in SLF4J I would have used that as > the API for Log4j 2 (I am quite happy we didn’t). > The Log4j migration issues from Log4j 1 to 2 fall into two categories IMO: Configuration and custom appenders. For me at work, our app server is still on r1 because we decided to not put too much time into maintaining or evolving the product and I have two newer products to work on, which I started with Log4j 2 since day 0. Our app server tools would need to be updated to automatically convert log4j 1 prop files to log4j 2 XML files, not a trivial task. Our users click this and that in a GUI to configure logging, so we have to do it all. Porting our appenders would be a week of work or so, no big deal, but still a week not spent on other tasks. I do see a need for a prop file porting tool but I am not sure how much of a need that is in the whole wide world. That or have the compatibility layer automatically understand prop files. Gary > Ralph > > On Aug 14, 2015, at 2:34 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Something to think about after we get 2.4 out the door... > > Do you think it appropriate for us to do some kind of outreach to other > Apache projects and say "hey, about about use log4j 2?" > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
