On Mon, 2005-05-23 at 21:27 +0100, robert burrell donkin wrote: > > (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.
Sorry, I don't understand. Why can't people compile against commons-logging.jar? > > 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. I don't see why this would be true. What configurations does an api jar support that a full commons-logging.jar won't? > > 3. backwards compatibility. (would need a 1.1 release at least.) I'm happy with making the next release 1.1. It should be totally backwards-compliant anyway. > > (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. Yep, it's hard to be confident we've understood the situation completely until we get feedback from people in the field. But the fact that they can turn on diagnostics and email us the output should improve that situation greatly. As you say, we could be a bit careful about the wording of the error message, just in case it turns out that there are some other situations that trigger the same message...eg "This is probably caused by ..." > > > (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. +1 > > > (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. I actually believe that JCL has been criticised for leaking memory in situations where *people who haven't analysed the problem properly believe weak references would solve the issue*. I don't believe that weakrefs *will* solve the problem in those situations. But I don't think the weakref stuff does any harm either (as long as there are no bugs in it!). So I'd be -0 to including it, not -1. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
