Quoting Marcelo Moreira <[EMAIL PROTECTED]>: > On Thu, 9 Dec 2004 16:33:33 -0600, Jacob Kjome <[EMAIL PROTECTED]> wrote: > > Are you trying to enable logging for Tomcat, your webapp, or both? You > will > > need to add both log4j.jar and commons-logging.jar (not > > commons-logging-api.jar) to common/lib to enable Log4j logging for > Tomcat-5.5.x > > itself. For your own app, do you use actually use the commons-logging api > or > > just the Log4j api? If the latter, don't bother with commons-logging. In > > fact, try to avoid it like the plague. If you do require commons-logging > for > > your webapp logging, I'm not entirely sure whether it is ok to have > log4j.jar > > in WEB-INF/lib and commons-logging.jar in common/lib or if they have to be > > together. There could be classloader issues if you separate them. I'm not > > really sure. commons-logging issus are outside the scope of my knowledge. > > Thanks for the answer. I am trying for both. commons-logging.jar + > log4j.jar are in commons/lib. But here is the question: I do not see > why they also have to be on the webapp WEB-INF/lib, since it should be > shared because they are already on commons/lib. >
If you share the common/lib instance of Log4j with your webapp, you will be using the same logger repository as the application server. There is one configuration per logger repository. If force reconfiguration within this already configured logger repository, your old configuration will be blown away. The idea Putting another copy of Log4j.jar in WEB-INF/lib in addition to the one in common/lib is to take advantage of Tomcat's classloading behavior which is child first (recommended by the servlet spec) rather than parent first (normal Java2 classloading behavior). Because each webapp looks locally for libraries first, it will find an instance of Log4j that is not in use by any other application. Therefore, the default logger repository will be distinct from that of the server and from that of any other webapp. You can configure to your hearts content without stompting on others' logging configuration. There is a way to separate application logging while sharing the same instance of Log4j and that is by using a repository selector. I would avoid this until Log4j-1.3 is released. It is more difficult to use a repository selector in Log4j-1.2. 1.3 makes it very simple. I recommend you use the first solution until Log4j-1.3 is released. > If I do not put them in the webapp WEB-INF/lib, logging for the webapp > does not work. > You are counting on autoconfiguration here. If you have an instance in common/lib, but not one in WEB-INF/lib, the logger repository of the one in common/lib will already have been configured by the time your app is initialized. Autoconfiguration is not performed more than once. Your webapp, in this case, will be using the configuration of the config file at the server level (in common/classes). Again, with a repository selector, your app config could be separated from the default logger repository. Note that in Log4j-1.3 you will need to perform configuration as there is no autoconfiguration, at least via classloader discovery of config files, on non-default logger repositories. > As I said, I got it working already, but this is just curiosity. > Hopefully I explained things better and piqued your curiosity about repostiory selectors in Log4j-1.3 :-) Jake > Thanks, > Marcelo. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
