First, while I've done a lot of the work up until this point Apache is a place where the community makes the decisions.
1) How stable is the API? We recently had requests to add at least one log(level, ....) method to the API. That will probably be done. We have also had a request to convert the Level from an enum back to an int. I'd like more community input on that one. It is likely new Message types may be added but other than that I don't see the API changing much. 2) My hope would be to see GA this summer, but again, it is up to the community. 3) Each Log4j 2 component is a maven sub-project. The javadoc for each is there. For example, under "Components" click on API. Then under "Project Documentation" click on "Project Reports" and then Javadocs. The pattern is the same for each component. 4a) I would actually recommend SLF4J over Commons Logging if the application is looking for an independent logging API. b) Again, many applications want an independent API. That is why they choose Commons Logging or SLF4J. As you noted, Log4j 2's API is not intended as a replacement for SLF4J but as a way for Log4j 2 users to know what is the public stuff they can safely code to and what is part of the implementation and thus, more likely to change. c) The commons logging bridge provides the binding between Commons Logging and Log4j 2. Ralph On Mar 24, 2013, at 1:08 AM, Nick Williams wrote: > I've been a Log4j 1 user for years and I love it. I'm currently writing a > book for Java EE 7 + Spring Framework 4 development and one of my chapters is > on application logging. I was going to cover Log4j 1 and then I stumbled upon > Log4j 2. It looks like a serious improvement over Log4j 1 and I'm quite > excited about it. There are three important things that I couldn't find on > the site (I read the entire manual, and looked at what I thought were all of > the pages, but it's possible I've missing something). I'm hoping someone here > can sort it out for me: > > 1) How stable is the API at this point? I understand the hazards of beta > software, but are we talking "it could be drastically different in six > months" or "chances are it won't change much from here on out?" I don't > expect a precise answer, just some guidance. > > 2) What is the /projected/ GA date? I know that dates are never certain with > open source software, and I don't expect somebody to tell me that it'll be GA > on July 21, 2013. But are we talking weeks, months, or upwards of a year? If > my book goes to press in November of this year, do I risk that Log4j 2 isn't > out by that time if I include it? > > 3) Where is the darned JavaDoc API documentation? I'm quite used to how easy > it is to find in the Commons, on the Tomcat site, and on the Log4j 1 site > (there's a big link that says "JavaDoc" in the sidebar). But I was rather > flabbergasted by the fact that I couldn't find any on the Log4j 2 site. > Specifically, I'm looking for the JavaDoc pages for the API, the > Implementation, and the Commons Logging Bridge. > > Also, I have a general question about the API versus Commons Logging. For > years my understanding, reading, and training have told me to use Commons > Logging so that the underlying implementation could be easily switched out if > needed (even though I have never strayed from Log4j). However, with Log4j 2 > it looks like the API being separated from the Implementation makes this an > unnecessary step, and could cause performance to suffer. So, I wonder: > > A) How important is using Commons Logging as a facade in front of Log4j > anymore? It sounds like it matters less now, and could cause performance to > suffer. > > B) Should libraries still use Commons Logging, but applications start using > the Log4j 2 API instead? > > C) Will my existing libraries using Commons Logging 1.1 play nicely with > Log4j 2? Or will they struggle to find a facility to log with? Do I need the > Commons Logging Bridge to make these existing libraries log properly (that's > what it sounds like, but I want to make sure)? > > Thanks in advance for any answers I receive! > > Nick > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
