[logging] make dependency on servlet api optional
anyone strongly object to me making the dependency on the servlet api optional (by altering the build script)? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
(getting back on track now, i hope) On Wed, 2005-07-06 at 13:21 +1200, Simon Kitching wrote: > On Tue, 2005-07-05 at 23:47 +0100, robert burrell donkin wrote: > > On Sun, 2005-07-03 at 11:51 +1200, Simon Kitching wrote: > > > > > > The memory-leak-in-servlet-engine issue is a common problem and does > > > need to be addressed one way or another. Taking a wild guess, I would > > > think that perhaps 50% of all uses of commons-logging is in a J2EE or > > > servlet container, so including this code in core seems reasonable to > > > me. > > > > that depends on whether the concept of core comes from a dependency > > perspective or a usage perspective. there are advantages in structuring > > builds so that dependencies can be managed most effectively and then > > distributing a combined headlining jar containing the most popular > > classes. > > By "core" I meant the jar that users are generally recommended to > download: commons-logging.jar. > > The ServletContextCleaner also needs to be in > commons-logging-adapters.jar as that is the jar recommended for webapps > where commons-logging or commons-logging-api is in the parent. that's fine by me. i'm happy with a fat commons-logging.jar so long as finer grained distributions can be built. what bothers me is the dependency graph for the most basic distribution. a good example of the problems that bigger graphs create is debian. JCL is depended upon by a lot of java libraries and debian checks that all dependencies will run on a free JVM. adding a dependency may mean that JCL and all components that depend upon it would have to be moved into contrib. > > > > I'd prefer a more modular approach: > > > > - Split the project (preferred, but not all that easy) > > > > - Provide several build targets according to dependencies > > > > - Compile "optional" (non-core, or less likely to be missed) components > > > > or features only if libraries they depend on are in the classpath. > > > > Issue a warning otherwise: "Component/Feature FooBar not compiled > > > > because FooLib not found..." > > > > > > This is pretty much what commons-logging currently does. So obviously > > > people share your view. > > > > there are several reasons why experience has taught that this approach > > often proves the best (i'll give some reasons for this statement at the > > bottom rather than break up the flow now). however, the modularity in > > the current build isn't as clearly reflected in the project structure as > > it might be. it might be worth considering a move to a structure better > > reflecting this (which may be Jörg's suggestion). > > There are two issues: > * modularity of the build > * optionality[1] of the build > > [1] This new word is copyright by me :-) -1 a coiner should be generous with those words he coins ;) > I've got no real objection to making the build more modular. I do think > making parts of the build optional is going to cause grief. we've been over this before so here's a summary. i'd like to see a minimal build which creates a JCL which will function in a very basic fashion for other libraries to depend upon. in addition, there would a number of modules capable of being build separately. i would support the primary user distribution being a series of fat jars but think that a minimal jar for use by libraries is important. expert users would be able to use the source to roll custom combinations. > > however, i'm now of the opinion that JCL requires lots more > > documentation than it has. IMHO optional jar's are much easier to > > explain than classloading. > > More docs are definitely needed. I don't see how having a set of jars is > going to help us avoid explaining classloader issues though. don't think i expressed myself very well: given that explaining classloading is difficult, we should be capable of explaining an optional jar. > > this can be addressed by looking at the jars we distribution. what works > > well with a modular approach is to separate the builds but distribute a > > fat jar (containing everything) as the standard (named) jar. > > > > adopting this policy would lead to a distributing something like: > > > > commons-logging.jar (containing everything) > > > > commons-logging-core.jar (containing everything but optional) > > commons-logging-optional.jar (optional stuff including deprecated) > > commons-logging-api.jar > > Yep, I could go for this. > > Personally I would generate this jar by compiling commons-logging.jar > then creating other jars with sets of classes extracted from the > "everything" jar. [but see comments re gump below] > > I get the impression that is not what you mean by "modular", and that > you would prefer to generate different jars then combine their classes > to create the "everything" jar. yes, that's the way i saw it working. suspect that this style works better with maven. agnostic about the practicalities, though. > > monolithic builds sooner or later run into diff
RE: [logging] make dependency on servlet api optional
> anyone strongly object to me making the dependency > on the servlet api optional I'd object if you DIDN'T. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
On Wed, 2005-06-29 at 23:00 +0100, robert burrell donkin wrote: > anyone strongly object to me making the dependency on the servlet api > optional (by altering the build script)? I would prefer to go the other way and make all of the compile-time dependencies mandatory. Currently the build.xml file is a mess with lots of conditional stuff: * if log4j is present compile the related classes. * if jdk14 or later, compile the jdk14 adapter class * if avalon is present, compile the avalon adapter class etc Given that all the jars are easily downloadable from ibiblio (we can even add an ant task to do this automatically) I don't see why any of this is necessary. And it means that people can generate jars with name "commons-logging-x.yy.jar" whose contents vary depending on what jarfiles are present. I don't call that a repeatable build process myself. People who want customised versions of commons-logging jar files with only some classes present can then unpack the resulting jar, delete the unwanted files and re-jar. TO me the benefits of a simpler and more predictable build process outweigh the benefits of conditional compilation (avoiding download of a couple of dependency jars). By the way, Robert, do you have a link to information about "dependency management tools" or whatever they were called that you mentioned when this servlet-api stuff was first discussed? I would be interested in learning what these are.. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
On Thu, 2005-06-30 at 10:02 +1200, Simon Kitching wrote: Sorry, please make this: If we make all compile dependencies mandatory then > People who want customised versions of commons-logging jar files with > only some classes present can then unpack the resulting jar, delete the > unwanted files and re-jar. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] make dependency on servlet api optional
On Wed, 2005-06-29 at 17:51 -0400, Noel J. Bergman wrote: > > anyone strongly object to me making the dependency > > on the servlet api optional > > I'd object if you DIDN'T. This is only a *compile-time* dependency. Currently there is a single utility class provided in the standard logging jar which can be used to avoid memory leaks when using commons-logging in servlet containers. The presence of the class doesn't do any harm when used in non-servlet-containers; commons-logging will run fine and the class is simply not used. Given this, do you still have an issue with including a class in the standard jar which needs servletapi.jar to compile? If so, please indicate what the problem is. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
At 12:00 AM 6/30/2005, robert burrell donkin wrote: anyone strongly object to me making the dependency on the servlet api optional (by altering the build script)? There are both advantages and disadvantages to each approach. Making parts of the build optional makes it easier for newcomers to build your system. On the other hand, the outcome of the build process becomes less deterministic. Requiring all dependencies to be present before building ensures that the outcome of the build process is complete. However, it makes it harder for newcomers to build your system, even when a partial build could have met the newcomer's needs. - robert -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
On Thu, 2005-06-30 at 11:50 +0200, Ceki Gülcü wrote: > > At 12:00 AM 6/30/2005, robert burrell donkin wrote: > >anyone strongly object to me making the dependency on the servlet api > >optional (by altering the build script)? > > There are both advantages and disadvantages to each approach. > > Making parts of the build optional makes it easier for newcomers to build > your system. Yes and no I think. If they are all mandatory then the build instructions are: * download them all * build Otherwise the instructions are: * download the bits you want (including docs we have to write and the user has to read about why they might or might not want different bits) * build > Requiring all dependencies to be present before building ensures that the > outcome of the build process is complete. However, it makes it harder for > newcomers to build your system, even when a partial build could have met > the newcomer's needs. In the old days, finding the necessary bits was indeed a nuisance. But today we can just provide a URL to ibiblio and say "download the necessary bits". Or we can even provide an Ant task that does that automatically; I've used this with great success before. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
Simon Kitching wrote: On Thu, 2005-06-30 at 11:50 +0200, Ceki Gülcü wrote: At 12:00 AM 6/30/2005, robert burrell donkin wrote: Requiring all dependencies to be present before building ensures that the outcome of the build process is complete. However, it makes it harder for newcomers to build your system, even when a partial build could have met the newcomer's needs. In the old days, finding the necessary bits was indeed a nuisance. But today we can just provide a URL to ibiblio and say "download the necessary bits". Or we can even provide an Ant task that does that automatically; I've used this with great success before. We could do some conditional logic in the build file to fetch the jars from ibiblio if (and only if) the defined dependencies are not present. Something like this: ... http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.9.jar"; dest="log4j-1.2.9.jar" unless"log4j12.present" ignoreerrors="true"/> ... If the user has not set the properties for the dependency jar files, the first build would download the jars from ibiblio. By placing the jars as specified by the dependency properties, the next build will not download the file again. Trouble might occur if the user is not connected to the internet or if ibiblio is down. Also we may need to set the property log4j12.present after the download. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
Simon Kitching wrote: This is only a *compile-time* dependency. Currently there is a single utility class provided in the standard logging jar which can be used to avoid memory leaks when using commons-logging in servlet containers. The presence of the class doesn't do any harm when used in non-servlet-containers; commons-logging will run fine and the class is simply not used. There's a recurring problem: projects developing into kitchen-sinks (Damn hard to avoid writing "kitching sink" here :-) ). I had to build Apache software from source multiple times for debugging purposes, and I don't like to track down all of the obscure compile time dependencies. Nor do I like to wait half an hour until all dependencies have been fetched from ibiblio or whatever. I'd prefer a more modular approach: - Split the project (preferred, but not all that easy) - Provide several build targets according to dependencies - Compile "optional" (non-core, or less likely to be missed) components or features only if libraries they depend on are in the classpath. Issue a warning otherwise: "Component/Feature FooBar not compiled because FooLib not found..." Take a look at the FOP build file to see the third approach in action. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
On Sat, 2005-07-02 at 21:29 +0200, J.Pietschmann wrote: > Simon Kitching wrote: > > This is only a *compile-time* dependency. > > > > Currently there is a single utility class provided in the standard > > logging jar which can be used to avoid memory leaks when using > > commons-logging in servlet containers. > > > > The presence of the class doesn't do any harm when used in > > non-servlet-containers; commons-logging will run fine and the class is > > simply not used. > > There's a recurring problem: projects developing into kitchen-sinks I don't believe this is the issue here. Commons-logging has a very definite focus so arbitrary feature growth is not really a danger. The memory-leak-in-servlet-engine issue is a common problem and does need to be addressed one way or another. Taking a wild guess, I would think that perhaps 50% of all uses of commons-logging is in a J2EE or servlet container, so including this code in core seems reasonable to me. > (Damn hard to avoid writing "kitching sink" here :-) ). I won't comment on this! > > I had to build Apache software from source multiple times for debugging > purposes, and I don't like to track down all of the obscure compile > time dependencies. Nor do I like to wait half an hour until all > dependencies have been fetched from ibiblio or whatever. Tracking down obscure compile time dependencies is not an issue; they are all right there on ibiblio. And we can provide an Ant task to download them. I guess for people on dial-up connections the download time could be a nuisance. > > I'd prefer a more modular approach: > - Split the project (preferred, but not all that easy) > - Provide several build targets according to dependencies > - Compile "optional" (non-core, or less likely to be missed) components > or features only if libraries they depend on are in the classpath. > Issue a warning otherwise: "Component/Feature FooBar not compiled > because FooLib not found..." This is pretty much what commons-logging currently does. So obviously people share your view. However it complicates things: * build.xml harder to read and maintain. For example, if building various parts is optional, then all the related unit tests also need to be made optional, and run only when the corresponding parts are present. * we need more documentation, and more complex instructions for users. It has to be remembered that commons-logging is generally something that people don't deliberately use; it's a dependency that is dragged along with some other lib that they are really interested in. So people don't have much interest in reading docs or configuring it correctly. Commons-logging really needs to work out-of-the-box as much as possible. And already people moan about having to include commons-logging.jar when using commons libs like digester or configuration. Providing them with complex documentation indicating under what circumstances they need to include additional jars won't make commons-logging more popular. > Take a look at the FOP build file to see the third approach in action. Yes, but FOP is quite a different beast from logging. People explicitly download and use FOP, while people usually get commons-logging as an accidental side-effect of some other lib. And commons-logging is only half-a-dozen classes while FOP is -- just a little bit larger! Note that I'm not trying to "shoot down" your view. I'm just putting the opposing case, and we'll see what the consensus is. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
On Sun, 2005-07-03 at 11:51 +1200, Simon Kitching wrote: > On Sat, 2005-07-02 at 21:29 +0200, J.Pietschmann wrote: > > Simon Kitching wrote: > > > This is only a *compile-time* dependency. > > > > > > Currently there is a single utility class provided in the standard > > > logging jar which can be used to avoid memory leaks when using > > > commons-logging in servlet containers. > > > > > > The presence of the class doesn't do any harm when used in > > > non-servlet-containers; commons-logging will run fine and the class is > > > simply not used. > > > > There's a recurring problem: projects developing into kitchen-sinks > > I don't believe this is the issue here. Commons-logging has a very > definite focus so arbitrary feature growth is not really a danger. > > The memory-leak-in-servlet-engine issue is a common problem and does > need to be addressed one way or another. Taking a wild guess, I would > think that perhaps 50% of all uses of commons-logging is in a J2EE or > servlet container, so including this code in core seems reasonable to > me. that depends on whether the concept of core comes from a dependency perspective or a usage perspective. there are advantages in structuring builds so that dependencies can be managed most effectively and then distributing a combined headlining jar containing the most popular classes. > > I had to build Apache software from source multiple times for debugging > > purposes, and I don't like to track down all of the obscure compile > > time dependencies. Nor do I like to wait half an hour until all > > dependencies have been fetched from ibiblio or whatever. > > Tracking down obscure compile time dependencies is not an issue; they > are all right there on ibiblio. And we can provide an Ant task to > download them. > > I guess for people on dial-up connections the download time could be a > nuisance. in my time, i've also spent too long tracking down obscure references when wanting to build a project just to hack a simple fix. (if you want real pain, then i'd suggest setting up a full gump run on a local machine.) but i agree with simon that maven now solves this problem very well. (indeed IIRC, this issue was one of those that maven was created to address.) > > I'd prefer a more modular approach: > > - Split the project (preferred, but not all that easy) > > - Provide several build targets according to dependencies > > - Compile "optional" (non-core, or less likely to be missed) components > > or features only if libraries they depend on are in the classpath. > > Issue a warning otherwise: "Component/Feature FooBar not compiled > > because FooLib not found..." > > This is pretty much what commons-logging currently does. So obviously > people share your view. there are several reasons why experience has taught that this approach often proves the best (i'll give some reasons for this statement at the bottom rather than break up the flow now). however, the modularity in the current build isn't as clearly reflected in the project structure as it might be. it might be worth considering a move to a structure better reflecting this (which may be Jörg's suggestion). i'm not really sure that the layout adopted works very well (a separate optional directory) and now we use subversion, it's cheap to reform the layout. (i do want to move the demonstration out sometime soon BTW.) > However it complicates things: > * build.xml harder to read and maintain. For example, if building > various parts is optional, then all the related unit tests also > need to be made optional, and run only when the corresponding > parts are present. true it's easier to go for an explicit module structure rather than use build tricks > * we need more documentation, and more complex instructions for users. true however, i'm now of the opinion that JCL requires lots more documentation than it has. IMHO optional jar's are much easier to explain than classloading. > It has to be remembered that commons-logging is generally something that > people don't deliberately use; it's a dependency that is dragged along > with some other lib that they are really interested in. So people don't > have much interest in reading docs or configuring it correctly. > Commons-logging really needs to work out-of-the-box as much as possible. +1 (but we all know how difficult that make it for us :) > And already people moan about having to include commons-logging.jar when > using commons libs like digester or configuration. Providing them with > complex documentation indicating under what circumstances they need to > include additional jars won't make commons-logging more popular. +1 this can be addressed by looking at the jars we distribution. what works well with a modular approach is to separate the builds but distribute a fat jar (containing everything) as the standard (named) jar. adopting this policy would lead to a distributing something like: commons-logging.jar (containing e
Re: [logging] make dependency on servlet api optional
On Tue, 2005-07-05 at 23:47 +0100, robert burrell donkin wrote: > On Sun, 2005-07-03 at 11:51 +1200, Simon Kitching wrote: > > > > The memory-leak-in-servlet-engine issue is a common problem and does > > need to be addressed one way or another. Taking a wild guess, I would > > think that perhaps 50% of all uses of commons-logging is in a J2EE or > > servlet container, so including this code in core seems reasonable to > > me. > > that depends on whether the concept of core comes from a dependency > perspective or a usage perspective. there are advantages in structuring > builds so that dependencies can be managed most effectively and then > distributing a combined headlining jar containing the most popular > classes. By "core" I meant the jar that users are generally recommended to download: commons-logging.jar. The ServletContextCleaner also needs to be in commons-logging-adapters.jar as that is the jar recommended for webapps where commons-logging or commons-logging-api is in the parent. > > > Tracking down obscure compile time dependencies is not an issue; they > > are all right there on ibiblio. And we can provide an Ant task to > > download them. > > > but i agree with simon that maven now solves this problem very well. > (indeed IIRC, this issue was one of those that maven was created to > address.) Ant can do this too. In fact I'll try to commit a patch to build.xml to auto-download all dependencies today. > > > > I'd prefer a more modular approach: > > > - Split the project (preferred, but not all that easy) > > > - Provide several build targets according to dependencies > > > - Compile "optional" (non-core, or less likely to be missed) components > > > or features only if libraries they depend on are in the classpath. > > > Issue a warning otherwise: "Component/Feature FooBar not compiled > > > because FooLib not found..." > > > > This is pretty much what commons-logging currently does. So obviously > > people share your view. > > there are several reasons why experience has taught that this approach > often proves the best (i'll give some reasons for this statement at the > bottom rather than break up the flow now). however, the modularity in > the current build isn't as clearly reflected in the project structure as > it might be. it might be worth considering a move to a structure better > reflecting this (which may be Jörg's suggestion). There are two issues: * modularity of the build * optionality[1] of the build [1] This new word is copyright by me :-) I've got no real objection to making the build more modular. I do think making parts of the build optional is going to cause grief. > however, i'm now of the opinion that JCL requires lots more > documentation than it has. IMHO optional jar's are much easier to > explain than classloading. More docs are definitely needed. I don't see how having a set of jars is going to help us avoid explaining classloader issues though. > this can be addressed by looking at the jars we distribution. what works > well with a modular approach is to separate the builds but distribute a > fat jar (containing everything) as the standard (named) jar. > > adopting this policy would lead to a distributing something like: > > commons-logging.jar (containing everything) > > commons-logging-core.jar (containing everything but optional) > commons-logging-optional.jar (optional stuff including deprecated) > commons-logging-api.jar Yep, I could go for this. Personally I would generate this jar by compiling commons-logging.jar then creating other jars with sets of classes extracted from the "everything" jar. [but see comments re gump below] I get the impression that is not what you mean by "modular", and that you would prefer to generate different jars then combine their classes to create the "everything" jar. > monolithic builds sooner or later run into difficulties with > dependencies. these difficulties come in different forms. > > there is the issue of dependency proliferation. the fight against > dependency proliferation means that good code that is only useful in a > limited number of use cases is not accepted whereas the ill effects of > drifting towards kitchen sink dependency are well known. monolithic > builds have to err on the side of caution. One could argue that the LogKitLogger is in this category - it's hardly ever used, and so it's debatable whether it should be included in the standard log4j jar. I agree that with the current setup, if something like LogKitLogger came along we would probably reject it as not being worth including in the standard jars. I don't quite see how a "modular" build would deal with this though.. > sooner or later, it is necessary to cope with dependencies which break > backwards compatibility. monolithic builds are usually force to adopt a > single choice of dependency. this causes major pain to downstream users > by forcing a particular choice of library versions upon. it is often
