On Thu, 13 Jan 2005, Ceki Gülcü wrote: | At 06:21 PM 1/13/2005, Ionel GARDAIS wrote: | >+1 | > | >Its also make log4j lighter when shipped into WARs. | | One of the important features in 1.3 is that you no longer have to | ship log4j.jar in WARs.
What if the servlet container does not provide log4j? It isn't exactly mandated by the spec. And what if I use log4j 1.3.5, that have this nice new feature, while the servlet container provides the old and boring 1.3.1? A feature that I'd -really- appreciate from the servlet-spec, is some kind of "log-dir" variable, that log4j could use as root for its configuration. In one of our apps, I've made a special variable that is set by the app to the mandatory servlet container provided "temp dir", unless you've set it yourself: $<productname>.log.dir. Using this, you can now configure all your file appenders relatively. If you don't provide the variable using -D switches (or whatever), you get the logfiles in the temp dir, while if you do set it, you'll get them where you want. This is nice - the log files do have somewhere to go in any case. (Another feature I'd love, is -extremly- simple: a way to know the context name (the "specific subset of the server's URL namespace") when the application is starting up, typically from the ServletContext. Now you only get it when a request actually comes in. This in particular related to the logging, logfile-location and config-location. ServletContext javadoc: There is one context per "web application" per Java Virtual Machine. (A "web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file.) ) Anyways, as long as you can bundle what you want with your app, I'm happy. Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
