On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote:
> Date: Fri, 07 Feb 2003 22:28:24 +0100 > From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [CLI] new design possibly? > > > Craig R. McClanahan wrote, On 07/02/2003 18.23: > > > > On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: > >> > >>Looks like an AOP-like system to intercept all logs of a package could > >>help, but I'm lost here. > >>> > > > > If you implement your own LogFactory, this is pretty straightforward, > > since it is your LogFactory instance that creates all the Log instances > > (even those declared static). > > What if other packages decide to make their factory? Can I somehow be > sure that I'm the top one deciding things? Ultimately, the person deploying the application makes an explicit choice of which factory class wins. You could, I suppose, design a log factory that was itself a wrapper around an arbitrary other LogFactory implementation -- if so, you'd configure both the choice of your wrapper as the "official" factory for commons-logging to use, and how it kwnows what other factory should be wrapped. > > Also, what about different classloaders. Would a single LogFactory work > with all of them? That's a really important question, especially in things like a servlet container. The current implementation of LogFactory.getFactory() configures a LogFactory instance per class loader. It also has support for using the thread context class loader to make this determination, instead of the class loader used to load commons-logging itself. This makes things work nicely in an environment like Tomcat, where you can have the API classes (commons-logging-api.jar) in a shared parent class loader, yet allow each app (loaded by a separate child class loader) configure its own LogFactory and logging configuration. > > Just trying to understand better. > > > I once had to integrate some libraries using commons-logging into an app > > that wanted to funnel log messages into logs (in the underlying > > environment) with different names than those used by the calling packages. > > This was accomplished by a trivially simple LogFactory implementation that > > performed the log name mapping and delegated to the existing impl for the > > work of actually creating the instance. > > > > The same approach would work (for example) to return a Log instance that > > was decorated AOP-style with extra functionality. > > Hmmm, seems cool. > > > No, it's not the strict IOC pattern that Avaloners really like. But > > there's more than one useful design pattern in the world, and the factory > > create pattern is pretty popular too :-). > > Yes, and speaking personally (not too loud ;-) I use it too with things > that are not coarse-grained components. :-) > Is simply does not make sense to > micromanage every logger and handle it to all children IMHO. One of the things I like about the way commons-logging is commonly used today (declaring an instance or static variable per-using-class) is that you *don't* have to configure anything, or remember to call setLogger() to avoid NPEs. It "just works" (tm), automatically adapting to how you've configured commons-logging, with no per-object configuration required. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
