axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <ceki_gu...@yahoo.com>
Subject Re: Common Logging Package
Date Wed, 07 Nov 2001 14:12:55 GMT

Richard,

I applaud you for starting this discussion and fully
share your concerns. At
this stage, the issue with logging (log4j vs. logkit
vs j.u.l. ) is
not technical but political. The political hurdles
have not been
surmounted in the past and I don't see the situation
changing anytime
soon.

With all due respect, in the absence of any political
compromise any
"shallow" technical solution including yours and
other's is just a
waste of time. This may sound harsh but it faithfully
reflects
reality. Best regards, Ceki

--- Glen Daniels <gdaniels@macromedia.com> wrote:
> Hi Richard:
> 
> Indeed, we had this debate several times on axis-dev
> :), and decided to go
> with log4j primarily because it was easy and
> available.  We expect to do
> pluggability for this release by building custom
> log4j Appenders that talk
> to other back-end logging systems (we're doing this
> for JRun integration,
> for instance).  It's not hard, but it does require
> writing a "pass
> everything through" log4j configuration.
> 
> One of the options we'd also considered was the
> Jakarta Commons log
> package - have you taken a look at that?  I'm not
> sure of its status, but it
> does pretty much exactly what you're looking for,
> has already been built,
> and works out of the box with log4j (use it if it's
> there, default to a
> System.out based solution if its not, and other
> logging backends can be
> plugged in as well).  I think it was in the
> "sandbox" area of the commons
> project last time I looked.
> 
> --Glen
> 
> ----- Original Message -----
> From: "Richard Sitze" <rsitze@us.ibm.com>
> To: "Greg Truty" <gtruty@us.ibm.com>; "Russell
> Butek" <butek@us.ibm.com>;
> "Sam Ruby" <rubys@us.ibm.com>; "Chris Barlock"
> <barlock@us.ibm.com>;
> <graham.hamilton@eng.sun.com>; "Cesare Giuliani"
> <cgiulian@tivoli.com>;
> <ceki_gulcu@yahoo.com>; <craigmcc@apache.org>
> Cc: <axis-dev@xml.apache.org>
> Sent: Tuesday, November 06, 2001 2:42 PM
> Subject: Common Logging Package
> 
> 
> > I'm sure this is going to spark some kind of
> annual (or semi-annual)
> > debate, so my apologies before I go any futher. 
> I've decided to copy a
> > number of folks that, as I understand, have an
> interest in this topic.
> >
> > I would like to take a more aggressive approach
> than I think has been
> > proposed in the past, so I hope that excuses this
> exercise.
> >
> > The bottom line is that I want a pluggable logging
> layer, that can be
> > replace at runtime with another.  NONE of the
> current logging packages
> that
> > I've looked at and NONE of the proposed logging
> packages use an interface
> > that allows pluggability.
> >
> > At the same time, I want to be sensative to
> runtime overhead (a past life
> > was with embedded system on a tight budget, so I'm
> a performance biggot
> who
> > has been struggled for air in the enterprise
> application arena :-).
> >
> > Before I go any further, I'd like to step back and
> introduce my situation
> > more clearly.
> >
> > I am working with AXIS developers and looking at
> integrating the AXIS
> > logging (and other open source tools in the
> future) with enterprise
> > application development tools and services.  AXIS
> is using Log4J today,
> our
> > products are using legacy logging tools.  We are
> not in a position to
> > change, any more than any other project... open or
> closed.
> >
> > As we integrate different open source projects
> into enterprise
> applications
> > we are going to end up with a plethora of logging
> tools under the covers.
> > In a worst-case (but realistic) scenario we are
> going to end up with
> > Enterprise applications using:
> >
> > * Log4J
> > * LogKit (Avalon)
> > * JSR47
> > * Proprietary Logging Interface (internal?)
> > * who knows what else...
> >
> > Leaving this as-is means that developers and
> end-users (customer) must
> > manage multiple configurations (enable/disable,
> filters, etc), multiple
> log
> > files, monitor multiple log files (with
> time-stamped records, hopefully),
> > and try to merge info together to gain a clear
> picture of sequential
> system
> > activity during debugging... bottom line: it's a
> headache.  It's simply
> > undesirable and unnecessary complexity for
> developers and end users.
> >
> > I see two solutions available:
> >
> > 1.  Write adapters/handlers for each of these that
> maps to the Enterprise
> > logging SPI.  Solves the multiple log files
> problem, but not the multiple
> > configurations.
> >
> > 2.  Push, as far as we can, a common/pluggable API
> that is covers 90% of
> > what logging interfaces do today.  I would argue
> that any remaining 10% is
> > glitter and glitz that could be done away with in
> exchange for reduced
> > complexity when integrating AXIS, Xerces, Xalan,
> Avalon, Eclipse, Tivoli,
> > etc into an enterprise application or development
> environment.
> >
> > In the short term it is likely that we are going
> to end up with (1)
> anyway.
> > In the longer term, I would hope that open source
> middleware would move
> > towards (2).
> >
> > Note also, that once (2) is completed, specific
> handlers that wrap (2) can
> > be packaged with Log4J/LogKit/JSR47.  From that
> point a quick bootstrap of
> > an application, using middleware bringing
> Log4J/LogKit/JSR47 together, can
> > be accomplished by writting a quick wrapper for
> the "proprietary logging
> > interface" using the same interface.  Granted that
> this is a "least common
> > denominator" solution, but it's a quick and easy
> one to get things
> started,
> > that could be replaced with something better
> later.
> >
> >
> > I'm proposing a common interface that can be used
> IF DESIRED.  I'm
> > proposing that Log4J and LogKit  implement that
> interface in their
> > Category/Logger classes, to eliminate concerns
> about wrappers and
> overhead.
> > I'm focusing on Log4J and LogKit as a model for
> this interface because a)
> > they are open source, b) they are in use and
> established, and c) they have
> > much in common.  Other logging interfaces will
> need to use thin wrappers -
> > which isn't much of an overhead when considering
> how Log4J and LogKit
> > implement the functions exposed in this
> interface...  Once that is
> > accomplished then we can let the community decide
> (that's what open source
> > is about, right?):
> > --  If they want to use Log4J, LogKit, JSR47, or
> whatever - then go for
> it.
> > --  If they want a very simple, rudementary, but
> pluggable API, with which
> > they can swap in/out Log4J (directly), LogKit
> (directly), JSR47
> (wrapper?),
> > JLog/JRas (wrapper?),  or other logger API, then
> they can use the
> > interface/factory.
> >
> >
> > There will be some impacts to both Log4J and
> LogKit.  Worst case, we end
> up
> > with bloated code (small wart, really) that works
> for both worlds
> > unchanged.  The discrepencies appear to be:
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

Mime
View raw message