I think log4j has some support for 3rd party loggers so it can do the work of determining the calling class but I don't remember the details. If Common.status updates the GUI I would level all calls to it the same. Then it is up to you to change all calls to Common.debug to Logger.debug depending on how much work that would be.
On Tue, Mar 25, 2008 at 8:08 AM, Clinton Weiss <[EMAIL PROTECTED]> wrote: > > I'm seeking some advice here. I have a legacy application with it's own > built in logging system accessed via Common.status(String) and > Common.debug(String). The status method is used to update the application > GUI's status line so the user has some idea of what is going on, it also > emits the String to System.out. The debug message just emits the String to > System.out. > > Now, I'd like to replace this setup with log4j, however, the pitfall is how > do I still let the user know what is going on? I believe I have a couple of > choices here: > > 1) Import log4j only in the Common class, and still allow all code to call > the status() and debug(). When status or debug are called, it will inspect > the current thread to see which class to pass to the logger and create (or > use a mapped) logger accordingly. This would probably be the easiest, but > not the correct way of doing it. > 2) Replace all Common.status(String) and Common.debug(String) calls with > logger.info(String) and logger.debug(String). However, can I create a class > that will listen for logger.info(String) calls and then can update the GUI's > status accordingly? This, I presume, would be the correct way of doing it - > if it is at all possible. > 3) Of course, you might have a better approach that I haven't thought of > yet. > > This in-house-only application has a pluggable architecture that accepts > three different types of Interface classes, which is why there is a single > place for logging. When I wrote it three years ago I was still very early > in Java and hadn't learned of the tools available to me just yet. Lately, > I've been planning an overhaul of this application and implementing log4j is > a high priority. All existing plugins are kept in a central repository, > therefore updating them to the new logging mechanism, if necessary, will be > easy. > > Any ideas? > Clinton > > -- > > > > > Clinton V. Weiss > Programming Services > Phone: 586-752-9671 Ext 143 > Fax: 586-752-6589 > www.custdata.com > CONFIDENTIALITY NOTICE: This email contains information from the sender > that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise > protected from disclosure. This email is intended for use only by the person > or entity to whom it is addressed. If you are not the intended recipient, > any use, disclosure, copying, distribution, printing, or any action taken in > reliance on the contents of this email, is strictly prohibited. If you > received this email in error, please contact the sending party by replying > in an email to the sender, delete the email from your computer system and > shred any paper copies of the email you printed. -- James A. N. Stauffer http://www.geocities.com/stauffer_james/ Are you good? Take the test at http://www.livingwaters.com/good/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
