"Craig R. McClanahan" wrote: > > 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 just thought it might limit the usefulness of a component, or potentially force the consumer to live with problems due to the use of that design. I'm glad to see it is possible to still use the commons components within multiple webapp contexts even though commons-logging is shared. Thanks for the info. I still wonder about the use case of a application that uses commons-pool (assuming it would use commons-logging) in two packages and would prefer to have the logging segregated along the package lines. E.g. myapp.foo and myapp.bar both using the pool code for different reasons. Assuming this is possible, just ignore me until I actually need to do this and I look for a way to accomplish it. Thanks, john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
