Hi,
I thought I would try and summarize the views expressed so far regarding
logging in components and present a point or two that may have been missed
in the discussion. I will also illustrate with a couple examples to show why
I think a simple logging API may be deficient for properly logging in
components that are aggregated to make a whole application.
I think that for smaller components like httpclient, or the digester the
simple logging API is sufficient as you primarily want an easy way to debug
the component within your application. But as a general logging API I don't
believe the proposed API scales well to larger components.
I will use Velocity and Fulcrum (services framework split off from Turbine)
as examples of larger components that are commonly used by Turbine
application developers. As far as I can tell simple logging API allows for a
single target which I feel is a limitation in larger components like Fulcrum
or Velocity.
Fulcrum I consider a component but itself consists of many different
services. I believe a logging API should allow any desired level of
granularity, in the case of Fulcrum if I wish to have a log file for each
individual service that should be possible. Or I might want the errors
generated by FooService to be emailed to an administrator, and the errors
for BarService to be sent to a central logging server. Now to do this you
require an API that allows you to obtain an instance of a category/logger in
each class, this is what is required for this type of granularity. Some
people might not want to do this in their code but it should be possible.
Another example is Velocity as a component. I would like to be able to
direct reference errors to a single file or an email account, and direct
resource loader related errors to another file. Log4j fully allows this and
it is very easy to setup a log4j configuration to direct output to any
desired location. Both log4j and the logging API allow this arbitrary level
of granularity and flexibility with targets. A simple logging API basically
masks this functionaility and IMO cripples a great tool like log4j. And as
soon as you start trying to provide this functionality you are stepping into
territory that log4j already has well covered.
Again, the pattern of retrieving an instance of a category/logger in every
class might not be appropriate for every component but I definitely think
that this pattern is required in larger components where the logging
requirements are unknown and may change as an application project evolves.
Using log4j any of these requirements can be met by altering a configuration
file.
I myself don't see a 25k jar as that big of a deal. All large applications
are going to require logging. Log4j is pretty much the defacto standard and
I don't think that we'll have a hard time convincing people to use it if it
is adopted here. We also have to hope that automated build systems based on
gump and jjar will make this process easier, so having to download an extra
jar (that people probably already have anyway) is probably not that big of a
deal. And if we push log4j as a standard, and I think we should, than it
will soon be something that everyone has. And if someone has to download a
25k jar for logging than they will only have to do it the first time they
download a commons component. I don't think this is an odious burden.
I know that people have wanted to make a simple logging interface to allow
flexibility in logging but I believe that log4j has already done this and
Ceki et al have taken great care to make a package that provides a set of
interfaces that scales well in a system where components are of varying size
and complexity and it provides default implementations. I think any logging
initiatives should be done within the context of log4j as it is the jakarta
logging project. It is more widely accepted than any other package by a
landslide and it is incredibly robust. I've never had single problem using
it or integrating it with the various legacy logging systems I've had to
deal with.
We could also work on some standard appenders for hooking into servlet
logging and logging in EJB environments so that we can make it as easy to
use as possible though I think log4j is very easy to use as it stands.
I really donšt see any downside to binding to log4j in the components. Log4j
can easily integrate with anything that comes down the pipe in the future.
I think this would also be a step toward making a component API for all the
commons projects can use. We can start with logging and go from there :-)
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
