On 8/1/01 5:43 AM, "James Strachan" <[EMAIL PROTECTED]> wrote:
> Hi Jason
>
> I totally agree.
>
> I think we need to pick one simple logging interface and I think log4j
> should be it - I see no value whatsoever in rolling our own again.
>
> Why don't we try arrange for a 'log4j-micro.jar' distribution which offers
> very basic logging features out of the box but is API compatible (using a
> small subset of log4j's code) - then folk can switch out log4j-micro.jar to
> logj4.jar and get the full version?
>
> (Though at 60k maybe we already have log4j-micro.jar ;-)
I think this is possible, I chatted with Ceki yesterday and it looks
like he put something together :-) I think something on the order
of 20k is perfectly reasonable to include with components.
> James
>
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 31, 2001 7:34 PM
> Subject: Re: [httpclient] log4j redux
>
>
>> On 7/31/01 1:58 PM, "David Winterfeldt" <[EMAIL PROTECTED]> wrote:
>>
>>> I made a simple logging interface so I could switch
>>> from standard out, the servlet log, log4j, or the sun
>>> logging api (only standard out and the servlet log are
>>> implemented). It isn't a complete logging interface,
>>> but it is the general idea. If you want to look at
>>> it, it is in cvs.
>>
>> There are 10 of them lying around jakarta, velocity has one, there's
>> one in tomcat, yours, there was one in turbine. I do not see any
>> benefit in using any of these interfaces over log4j. No simple
>> logging interface is going to come anywhere close to features
>> that log4j provides. It is 60k for the core bundle, but everyone
>> needs logging and I think we should settle on something that
>> is well tested and has worked for literally hundreds of projects
>> already.
>>
>> In time it will probably come down to log4j or the Sun logging
>> API and they work in a very similar fashion and it would not
>> be hard to switch from one to the other because the semantics
>> are so close and they are getting closer after Ceki pointed
>> out some of the drawbacks of the logging API.
>>
>> We could also work on making a skeletal version of log4j that
>> could be very small. I think we should work in this in the context
>> of the highly successful logging project we already have instead
>> of trying to roll yet another logging interface that is non-standard.
>>
>>> ValidatorLog (interface), DefaultValidatorLog
>>> (Standard Out), HttpValidatorLog
>>>
>>>
> http://cvs.apache.org/viewcvs/jakarta-struts/contrib/validator/src/share/com
> /w
>>> intecinc/struts/validation/
>>>
>>> David
>>>
>>> --- "Waldhoff, Rodney" <[EMAIL PROTECTED]>
>>> wrote:
>>>>> As appeared to be generally agreed upon, HTTP
>>>> client shouldn't
>>>>> have dependencies with log4j
>>>>
>>>> Not that such a vote is particularly meaningful here
>>>> (at least as I
>>>> understand it), but I counted at least three +1s for
>>>> the log4j support.
>>>>
>>>>> (Rodney, do you plan to revert that part of your
>>>> latest patch ?)
>>>>
>>>> If I must. What I'd really like to do is replace
>>>> with some lightweight
>>>> (pluggable?) logging mechanism that is agreeable to
>>>> everyone and supports
>>>> log4j (and potentially other logging mechanisms as
>>>> well). I think that
>>>> would meet everyone's needs as I understand them.
>>>> Failing that I guess we
>>>> either rip out logging entirely or go back to
>>>> stdout/stderr logging except
>>>> provide a built-in way to turn it on and off via a
>>>> property setting.
>>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Make international calls for as low as $.04/minute with Yahoo! Messenger
>>> http://phonecard.yahoo.com/
>>
>> --
>>
>> 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
>>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
--
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
