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:[EMAIL PROTECTED] > Sent: Monday, June 07, 2004 9:58 AM > To: Avalon Developers List > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
