> How does the interceptor approach work?
Aren't you familiar with Velocity Jason?
Velocity has a common Log interface allowing to plug multiple log
systems. It comes with adapters for Log4j and Avalon's LogKit.
You find the logging stuff at the org.apache.velocity.runtime.log
package. Does it have to be much less simpler than this?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 28, 2001 5:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [httpclient] logging and testing changes
>
>
> 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
>
>
