[
https://issues.apache.org/jira/browse/ZOOKEEPER-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olaf Krische updated ZOOKEEPER-850:
-----------------------------------
Affects Version/s: 3.3.1
Release Note:
introduces indirection for logging via slf4j-api. adding bridge from slf4j to
log4j implementation.
1) added "slf4j" dependency in ivy.xml
2) replaced:
- "import org.apache.log4j.Logger" with "org.slf4j.Logger,LoggerFactory"
- "org.apache.log4j.Logger with "org.slf4j.Logger"
- "org.apache.log4j.Logger.getLogger" with "org.slf4j.LoggerFactory.getLogger"
3) replaced log.fatal with log.error, slf4j api has no log.fatal, faq
recommends log.error
4) fixed logging requests, like "log.error(object)" with
"log.error(String.valueOf(object))" to match slf4j api
5) removed direct log4j-api access from
"org.apache.bookkeeper.util.LocalBookKeeper" in contrib.
it added programmatically a console appender to the existing logger in the
constructor. this can be done anytime via log4j.properties (which had by
default INFO,CONSOLE anyways)
Status: Patch Available (was: Open)
So, in a way, i didnt change much. All what is required now is to have those
two extra slf4j-jars in the classpath. Then it should run as always. Even if
there is still a mistake, since log4j is still there, all should work as always.
The "org.apache.zookeeper.jmx.ManagedUtil" has to go away. Why not as an extra
utility in contrib? It manages log4j by jmx. So therefore it requires log4j. I
didnt wanna do a structural change.
You can remove "log4j" from ivy, then you will see the last dependencies, when
building.
ant test tar went thru without a problem.
> Switch from log4j to slf4j
> --------------------------
>
> Key: ZOOKEEPER-850
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-850
> Project: Zookeeper
> Issue Type: Improvement
> Components: java client
> Affects Versions: 3.3.1
> Reporter: Olaf Krische
>
> Hello,
> i would like to see slf4j integrated into the zookeeper instead of relying
> explicitly on log4j.
> slf4j is an abstract logging framework. There are adapters from slf4j to many
> logger implementations, one of them is log4j.
> The decision which log engine to use i dont like to make so early.
> This would help me to embed zookeeper in my own applications (which use a
> different logger implemenation, but slf4j is the basis)
> What do you think?
> (as i can see, those slf4j request flood all other projects on apache as well
> :-)
> Maybe for 3.4 or 4.0?
> I can offer a patchset, i have experience in such an migration already. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
