--- Simon Kitching <[EMAIL PROTECTED]> wrote: > 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? > I believe it allows a child to use commons-logging.properties to specify a logging library that is not visible to the parent. With only the -api jar in the parent, the Log adapter will be defined by the child and will thus be compatible with the library.
See examples 10 and 10.i in http://xnet.wanconcepts.com/jcl/furtherAnalysis.html > > > > 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] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
