On 7/27/01 8:36 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>
> Ok, I can understand why we would want to have integrated logging as a
> convinience feature for the application. However, I'd like to have the
> client go into no logging by default, and have the application use the
> interceptors to log what it wishes to log. I believe the current
> interceptors should be enough for that task (but we can add additional hooks
> if it's not the case).
Logging in components is going to become a problem. Every project at
Jakarta seems to have its own logging solution but something common
would has to surface. In Turbine I pushed to use log4j instead of the
logging interface we previously rolled ourselves. I also pushed to use log4j
in Fulcrum and Torque that were spun off from Turbine (services framework,
and persistence layer).
My reasoning was that log4j has done a good job at dealing with logging
and there's no reason to try and roll another system. I consider log4j
the logging interface. If I need to integrate another logging system
I simply make a log4j appender that adapts the other logging system
to log4j. I figure that eventually it's going to boil down to using
log4j or the Sun logging API and I went and picked log4j because I
find it to be outstanding. Logging has never been so easy and flexible.
What if the log4j developers made a really tiny core package, say 10-15k
that provided the bare minimum for logging? Would people be willing to
use it then?
How does the interceptor approach work?
I wanted to use log4j in Turbine, Fulcrum and Torque because it's very
easy to customize the logging from a properties file or xml configuration.
If I were to combine all the components in the commons in an application
how would I achieve consistent, uniform logging? Is this possible now?
If not, we should think about how this will work whether it's a micro-logger
interface, using interceptors or whatever because I would like to use
the same method that is decided upon here in the turbine packages.
I know in turbine that we will be using almost all the commons packages
eventually and the logging has to be easily configurable. I know from
using log4j that with simple changes to a properties file you can control
the logging from each component used in your application.
I don't think a micro-logger interface can provide the flexibility
that log4j already does. I am not familiar with interceptor approach.
I am going to be splitting more pieces out of turbine so I would really
like to have a common strategy for logging and here is probably the
place to hash it out.
If all projects are going to use a common logging strategy than this
strategy will be contained in a JAR and I think the log4j developers
would be will to work on something that would satisfy any requirements
that might arise. I would really not like to roll another logging
solution.
> What do you think ?
>
> Craig made (on tomcat-dev) some very valid points against log4j and its
> equivalents, and why the "if (debug) then log" is the right solution in many
> cases.
Do you have the tag line for this message, I would like to read it.
> Remy
--
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
