Ceki,
Wouldn't this be another good example of a case where allowing your own
repository selector is a good idea?
I discussed this before:
http://marc.theaimsgroup.com/?t=10148577083&r=1&w=2
I suggest that until 1.3 is released (which *should* deal with this
problem by having separate lo
Hello Ceki,
So, being somewhat new with Log4j, are you saying that given the fact
that Tomcat does not do RepositorySelectors for me and also doesn't
give me control of the context, that it would be pretty difficult to
figure out how to write a custom RepositorySelector? Are there any
examples t
Jake,
Very good question.
Log4j 1.2 introduced the concept of RepositorySelectors specifically
to deal with this problem. Unless the container does for you (which
Tomcat does not) you'd have to write your own RepositorySelector.
Writing a selector is trivial if you control the application
conte
The reason that it should be in WEB-INF/lib & not int TOMCAT_HOME/lib is
that log4j used to have problems loading the config file if you used the
server library path.
This is because the server classloader cannot see anything in the
application classloader.
If you are using a single configura
, May 30, 2002 8:52 AM
>To: [EMAIL PROTECTED]
>Subject: Log4j and Tomcat apps
>
>
>I was reading the Log4j manual and it suggests that for each webapp, you
>should use a separate log4j jar file in each WEB-INF/lib to make sure that
>each log4j is in its own "log4j Universe&
I was reading the Log4j manual and it suggests that for each webapp, you
should use a separate log4j jar file in each WEB-INF/lib to make sure that
each log4j is in its own "log4j Universe". However, this puts constraints
on where I put my libraries that use log4j. For instance, if I have lo