On Sun, 2005-05-22 at 13:54 +1200, Simon Kitching wrote: > Hi, > > ========================= > I would like to propose the following for jcl 1.0.5: > > (a) > That we build diagnostic output into LogFactory/LogFactoryImpl which > users can turn on via a system property. NB: I'm about 80% done with the > implementation for this.
+1 good work > (b) > That in addition to commons-logging.jar we distribute a > "commons-logging-adapters.jar" which contains the entire contents of the > "impl" subdirectory, ie all the logging adapters and the concrete > LogFactory subclasses, but specifically NOT > * LogFactory > * Log > > [this is along the lines of Brian's jar-refactoring proposal] > > We should do away with commons-logging-api.jar; it serves no purpose. -1 a few reasons: 1. it is vital for dependency management. it is very important that JCL ships a dependency free jar for compilation and dependency management. the main flaw with the api is that it's too big and not viable by itself. 2. it is useful for certain parent first configurations. replacing an full jar with an api jar allows some parent first configurations to log to log4j. 3. backwards compatibility. (would need a 1.1 release at least.) > (c) > That we change the error message when multiple Log instances found, to > state that child should contain -adapters.jar not full jar. +1 we need to be confident about the diagnostics in this case before recommended definite action. (i believe that some exotic classloader configurations may also produce similar symptoms) i certain think that the wording should be improved but would welcome a reference to troubleshooting document (possibly an url?) which could provide more explanation and could offer advice for the more exotic cases. > (d) > That we provide the deployment instructions listed at the bottom of this > email. in some ways discovery deployment instructions are both needed and a contradiction. discovery is supposed to guess right but sometimes it needs a little help. JCL needs a troubleshooting document. (i even made a start on one a while ago.) the deployment instructions/recommendations would fit very, very into such a document. i like having information on the web (rather than in release notes etc). not only is it easy to reference when answering user questions but it's also easily indexed by search engines. if this sounds like a good plan, i'll try to pull something along those lines together in the next few days. > (e) > That we remove the weakref stuff that was added since 1.0.4 (sorry, > Brian!). The problem is that having Log deployed via the parent loader > and subclasses of Log (eg Log4JLogger) deployed via the child > classloader creates exactly the situation that renders the weakref stuff > useless. Instead, I would just document clearly that people should use a > ServletContextListener in situations where memory leaks matter. As I > describe below, I don't think it's all that often. We could also provide > cut-and-paste code to help them create and configure the > ServletContextListener - or maybe even bundle a suitable implementation > in the commons-logging.jar file. i agree that ServletContextListener is the preferred solution for web containers. i'd support an implementation shipping in the optional jar. however, i do think that there are configurations for other containers where the weak reference stuff may prevent or reduce memory leaks. JCL has been widely (and rightly) criticised for leaking memory in situations where this could have been avoided by using weak references. we have code that addresses these criticisms. i think we should ship it. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
