On 8/15/01 1:12 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 15 Aug 2001, Jason van Zyl wrote:
>
>>
>> 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.
>>
>
>> From the perspective of a potential user of Commons components, there
> would be a very important downside to locking the components in to using
> Log4J -- that forces the user to use Log4J whether or not they want
> to. (I'm not interested in arguments on why we might want to try to
> convince them otherwise -- not everyone is going to be converted :-).
If people are going to use commons components than they are going to have to
conform to something log4j or otherwise. They must use what we have chosen,
and my argument is still that the simple logging API is deficient for larger
components. My argument is that when you add the features that provide
logging features that can be used thoughout a family of components of
varying complexity you approach what log4j is.
> It doesn't matter to such users that they can write adapters and Category
> implementations and such -- they already have their own logging
> environment, and want to use *that* instead without having to learn
> Log4J's configuration formats, or enough internals to integrate it. To
> such users, tying commons components to Log4J will be a showstopper for
> using the commons components in the first place.
I honestly don't think it would be at all. I really think that people want
to use what's standard especially for such basic needs as logging. There
will be integration issues with any divergent logging tools but I think our
settling on something standard like log4j will help moves others toward
log4j.
> No argument that such a decision might not be rational - but this is
> reality.
>
> Note that the decision is different for something like Turbine, where you
> need more sophisticated logging capabilities.
Has nothing to do with Turbine, the examples of components I used are not
part of Turbine, and the real issue is ease, granularity, and flexibility
over logging facilities and nothing comes close to log4j.
> There, it makes perfect
> sense to choose a logging API and use it throughout, plus make it easy for
> applications developed on top of Turbine to take advantage of its
> capabilities.
It makes perfect sense for any component like a services framework or
something reaching that complexity where logging needs are certainly
different than those for a small single function utility like httpclient.
But log4j can deal with all cases very nicely.
> The decision for commons components should be based on different criteria.
I think the criteria should clearly be granularity, flexibility, ease of
use, ease of integration, scalabilty across varying components. Log4j deals
with all of these unlike the simple logging API we have now.
>> 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 :-)
>>
>
> Note that, the way the current abstraction layer works, it defaults to
> Log4J anyway if the classes are visible, so integrating commons components
> into an environment already using Log4J reqauires nothing you aren't
> already doing in terms of configuration.
This cripples the features of log4j, you can't use anything that makes log4j
an amazing tool. It's like cutting log4j off at the knees.
> And, if you don't have Log4J installed, any log output created by Commons
> comopnents is silently thrown away -- you don't have to care at all about
> logging unless you want to.
This than should also be added to criteria list and we should find a way to
make log4j do this. Possibly a little bootstrap class or something, I'm sure
Ceki might have some ideas. If this criteria was met, full transparency,
would you than consider using log4j?
>> --
>>
>> jvz.
>>
>
> Craig
--
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
