Craig, Just to clarify, you wrote a LogFactory impl, and put it in the shared lib dir (so all apps can use the same instance)?. If so, how do you determine which app to rename the category for? I can't think offhand of knowing a particular instance / Class instance is in a particular app, since no context is passed back (unless there's something on the thread? Thread context ClassLoader?).
Or are you putting the LogFactory per app? I don't see how this could work though.. Ken. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 22 April 2002 19:12 To: Jakarta Commons Developers List Subject: Re: [LOGGING] ClassLoader Problems On Mon, 22 Apr 2002, John McNally wrote: > Date: Mon, 22 Apr 2002 10:58:16 -0700 > From: John McNally <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Subject: Re: [LOGGING] ClassLoader Problems > > It does not seem that static factory methods like > > Log.getLogger(String) or Category.getInstance(String) are the best way > > to invoke logging within a component meant to be used within a larger > > system. > > > > I should say it might not be a bad way to invoke the logger, but > hardcoding the String key to be the classname where the logger is used > appears to be a bad choice. A component needs to have a way to allow > the system using the component to override the region/category. > "Good" versus "bad" is a pretty emotion-laden discussion starter :-) I would point out, though, that the existing commons-logging implementation lets you accomplish precisely the goal you specified, without requiring a setLog() or equivalent method on the component itself. As a test of this, I wrote a trivial LogFactory implementation whose getInstance() methods simply renamed the one requested by the component to match an application-specified hierarchy. This works even if the component itself thinks it is asking for a logger named after the component class itself, with: private static Log log = LogFactory.getLog("my.class.name"); This approach accomodates lots of other options -- from "make all the components share a single Log implementation" up to very sophisticated sharing approaches. Personally, I find that this feature, coupled with the hierarchical configuration supported by Log4J (I can set a default logging level for "org.apache" to cover all my Apache-source components, and then override it for just "org.apache.foo.bar") makes a very flexible paradigm, without imposing any requirements on the components themselves (except to document what logger names they use :-). > john mcnally Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
