commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject RE: Starting work on UGLI
Date Mon, 07 Jun 2004 15:49:46 GMT
Eric,

On Mon, 2004-06-07 at 09:26, Eric Pugh wrote:
> How is UGLI different from commons-logging?  I don't want yet another
> logging api to have to consider when writing my applications/components.

I don't think commons-logging takes into account any of the
configuration aspects associated with specific logging implementations
like log4j or the jdk's logger.  What Ceki seems to be proposing is a
superset of the commons-logger where the interfaces are extended to
handle log configuration through a generalized interface.  At least that
was my impression - please anyone correct me if I'm off.


> Any thing that makes logging simple would be great.
> 
> Eric

+1

> 
> > -----Original Message-----
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > Sent: Monday, June 07, 2004 9:58 AM
> > To: Avalon Developers List
> > Cc: log4j-dev@logging.apache.org; general@logging.apache.org;
> > commons-dev@jakarta.apache.org
> > Subject: Re: Starting work on UGLI
> >
> >
> >
> > Ceki:
> >
> > Ceki Gülcü wrote:
> >
> > >
> > > Hello,
> > >
> > > While working on the internal log4j logging, it occurred to me that it
> > > could be very useful to synthesize log4j's core user interface in its
> > > own package. I'd like to call this package Universal Generic Logging
> > > Interface or UGLI (pun intended).
> > >
> > > The word "universal" stands for applicability in all contexts,
> > > including stand alone applications, containers (EJB, Servlet, Nano,
> > > Pico, Avalon, whatever) and most importantly in specialized
> > > libraries. The word generic stands for very simple, with an absolute
> > > separation between the logging interface required to access logging on
> > > one hand and configuration of the logging system on the other.
> >
> > Sounds good.
> >
> > I'm presuming that the phrase "logging interface required to access
> > logging" is specifically the client interface against which a logging
> > message is invoked (as opposed to anything related to how an instance of
> > that interface is created).  Is that correct?
> >
> > The second phrase "configuration of the logging system" is somewhat
> > broader and I wanted to find out if your thinking about the general area
> > of how plug-in logging targets can be managed in a managed classloader
> > environment.  This subject is currently the major obstacle to the use of
> > different logging solutions and a common API for loading, deploying and
> > releasing plug-in target factories would be a big step forward.
> >
> > For reference - Avalon's work in this area is under the Avalon Logging
> > system which is a implementation independent framework for managing a
> > logging system within which we have two plug-in implementation
> >
> >     * LogKit
> >     * Log4J.
> >
> > http://avalon.apache.org/logging/impl/index.html
> >
> > The actual logging management API is described in the javadoc at
> > http://avalon.apache.org/logging/api/index.html (however keep in mind
> > that each plug-in logging solution has its own particular logging system
> > configuration).
> >
> > As far as the management side is concerned, do you see UGLI covering the
> > spectrum of management APIs and configuration schema (or maybe I'm
> > reading too much into your email)?
> >
> > Cheers, Stephen.
> >
> > --
> >
> > |---------------------------------------|
> > | Magic by Merlin                       |
> > | Production by Avalon                  |
> > |                                       |
> > | http://avalon.apache.org              |
> > |---------------------------------------|
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message