On Wednesday, August 03, 2011 12:03:45 AM Angelo zerr wrote:
> Hi CXF Team,
>
> I would like know why you have decided to use java.util.logging.Logger in
> your code and implements it with SFL4J, commons-logging...instead of using
> directly for instance SFL4J which very used in a lot of open source project.
> I like this idea not to be dependant of any Logger JARs, and I tell me if
> we will use this idea for our XDocReport project. Have you some limitation
> to use java.util.logging.Logger instead of using directly SFL4J?
Way back when we started writing the first lines of CXF, SLF4J wasn't really
an option, it didn't exist yet. :-) Thus, the choices really were commons-
logging (which sucked, still does), j.u.l.Logger, or Log4J directly. We
ended up just using j.u.l as it performed the best and the API's were
relatively clean and straight forward. A simple wrapper allowed using Log4J
as well.
As Benson mentioned, neither commons-logging and SLF4J support localized log
messages as part of the logger itself. Before calling the logger, you would
need to localize things and thus, you get a lot more
if (logger.isLogging(..)) {
String msg = ....use ResourceBundle or something.....
logger.log(..., msg)
}
which makes the code a lot crappier than just:
logger.log(level, "MSG_KEY", params)
The extra dependencies issue was also a concern. At the time, Apache Harmony
was beginning to ramp up and we wanted CXF to be the JAX-WS implementation
they would use. They didn't want any extra jars if they were not really
needed so using j.u.l was a better option there. Other projects also kind
of appreciate having fewer deps.
>
> Thank a lot for your answer.
>
> Regards Angelo
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
