At 12:13 08.06.2001 -0400, you wrote:
>Hi Ceki,
>
>I have a few issues that I would like to discuss, I need some advice
>as I'm doing some refactoring in Turbine and I'm not sure what the
>best practice is vis-à-vis logging in components and/or packages
>that are used by a parent application.
>
>I have just started some work on refactoring the Turbine services
>framework in order to add some additional functionality. One step
>is to clean up some of the logging interdependencies so any advice
>would be greatly appreciated. Right now the logging in the services
>depends on a sibling logging service which I don't think is the
>correct way to provide logging in components ...
>
>My initial response is to want to pass into the ServicesManager an object
>that encapsulates all logging capability before the ServicesManager
>initializes all the services.
>
>I use log4j for all my logging needs but when it comes to logging
>in components I might like to use the API provided in the JSR 047.
>Is the JSR 047 going to become standard for logging? Has anyone done
>any work to implement the JSR 047 API using log4j underneath?
Hi Jason,
The fundamental pattern is the following:
--------------------------------------------------------------
Log4j makes it easy to name categories by software component. This can
be accomplished by statically instantiating a category in each class,
with the category name equal to the fully qualified name of the
class. This is a useful and straightforward method of defining
categories. As the log output bears the name of the generating
category, this naming strategy makes it easy to identify the origin of
a log message. However, this is only one possible, albeit common,
strategy for naming categories. Log4j does not restrict the possible
set of categories. The developer is free to name the categories as
desired.
--------------------------------------------------------------
Yes, there is an implementation of JSR47 with log4j underneath. It will be soon
included in the contrib/ directory of the log4j distribution.
This is from the log4j manual:
Sun has begun a community process, JSR47, in order to define a logging
API for java. This API will require JDK version 1.4. The JSR47
specification has recently became ready for public review.
The JSR47 API and log4j are quite similar at the architectural
level. JSR47 API will support a hierarchical name space, one of the
central features of log4j. On the other hand, log4j has many useful
features that are missing in JSR47. For example, log4j supports
appender inheritance, JSR47 doesn't. In log4j categories can be
initialized in any order, in JSR47 parents must be initialized before
children. See also the slides (http://www.qos.ch/ac2001/F11-200.html) from
my ApacheCon 2001 presentation on precisely this subject.
From time to time, users ask if log4j is "standard compliant". While
it is possible to be compliant with a protocol or a pluggable-API, it
is impossible to be compliant with an implementation. Either one is
the implementation or one is not. JSR47 is an implementation of a
skeleton logging API. It is not a specification or a communication
protocol. No API other than the JSR47 API will ever be compliant with
the JSR47 API.
Given the momentum behind log4j, in my partisan opinion, JSR47 is
likely to be obsolete by the time it is launched. Log4j is written by
the people who use it daily, not by a committee.
>I am looking ahead while
>thinking about splitting various pieces of Turbine out of the core:
>these separate pieces will operate independently but I want
>logging to be cohesive. I'm sure there's a lot of experience here
>WRT logging cohesively across a set of components which is why
>I'm asking :-)
My advice to you is not to encapsulate log4j as many enlightened
developers suggest. The day you want to dump log4j and use JSR47 you
can do so with a search and replace operation. Remember, the
fundamental pattern in the two API is the same:
X x = X.getInstance("some.name");
x.debug("hello");
x.info("world.");
where X is called "Category" in log4j and "Logger" in JSR47. The
search-and-replace pattern follows.
IMHO, encapsulation won't gain you much except grief. I also suggest
that you use log4j configurators instead of trying to configure log4j
programmatically. The log4j configuration files can live side by side
with the Turbine configuration files. (Log4j config files can be also
embedded in Turbine config files.)
>I have not looked at the components in the commons as they may
>already provide some answers: maybe tools like the DCP in the commons
>do provide a way to log cohesively. I will look.
>
>Any comments or thoughts would be greatly appreciated. I am working
>on separating out the services framework now and I would like to get
>it into the commons sandbox in a couple of weeks but right now I'm
>not clear on logging. I figured the best advice would come from here :-)
You question was generic, hence my generic answer. If you have
specific needs do not hesitate to ask more detailed questions. I hope
this helps and wish you good luck. Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
