logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <paul.sm...@lawlex.com.au>
Subject RE: log4j JMX implementation
Date Mon, 24 Nov 2003 22:45:10 GMT
On Tue, 2003-11-25 at 09:25, Jacob Kjome wrote:
> Ceki.  You are right here.  The server provides the JMX libraries in a parent 
> classloader, as it is the server providing the service.  In order for Log4j to 
> work with JMX, they must be in the same classloader.  As such, putting 
> log4j.jar in WEB-INF/lib in servers (like Tomcat) which load libraries 
> preferentially from the WebappClassLoader will not work.  In this case, the 
> default behavior of servers like JBoss and WebLogic is probably preferrable, 
> since it won't really matter where log4j.jar is (although one might run into 
> some log4j.jar versioning problems, which is the major reason for the servlet 
> spec recommended classloading scheme).  Under Tomcat, log4j.jar would need to 
> be in common/lib and removed from any webapp's WEB-INF/lib in order for this to 
> work.
> Jake

Since there could in theory be several JMX agents running within the
same VM, and that there are also several log4j repositories, we might
want to consider some sort way of allowing a client (as an example, the
class that creates and starts a particular JMX agent) to register a
particular MBeanServer with a particular log4j Repository, and the log4j
repository communicates with this MBeanServer therein to register
Loggers, appenders etc.).

Hope that makes sense.  I think I just confused myself.


Paul Smith

To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message