Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Reply-To: <epugh@upstate.com>
From: "Eric Pugh" <epugh@upstate.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: RE: Starting work on UGLI
Date: Mon, 7 Jun 2004 15:26:46 +0200
Message-ID: <PKENIMMEAHDAHILNLIJPAEDFEBAB.epugh@upstate.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Importance: Normal
In-Reply-To: <40C41FFF.1040108@apache.org>

How is UGLI different from commons-logging?  I don't want yet another
logging api to have to consider when writing my applications/components.

<begin rant>
I definitly don't want to have to implement another logging interface, and
after all the pain I've gone through attempting to grok various logging
packages, I often find myself going back to System.out.println and
System.err.println since I know they work.  Or, spinning my own logging
package that does exactly what I need and no more.   Not a great solution,
but a reaction to the complexity of what I think should be really be a very
simple (from the developer perspective) problem to solve.
<end rant>

Any thing that makes logging simple would be great.

Eric


> -----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