DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9305>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9305 Use thread context class loader for loading ------- Additional Comments From [EMAIL PROTECTED] 2002-05-22 09:35 ------- My response is that there is no need to choose Class.forName or the TCL. Simply add a setClassLoader(ClassLoader loader) method to the configurator and then it is the framework user's choice of how the framework integrates with its usage context class loading policy. Default the configurator loader to getClass ().getClassLoader() and there is no change in behavior by default. As to examples of where Class.forName fails: 1. Bootstrap a minimal app server with a minimal configuration with the log4j.jar in the classpath 2. Load the full app server configuration from a remote web server. This includes an extended log4j configuration and any number of filters, appenders, etc. that are loaded by the URLClassLoader associated with the web server. This is a child of the class loader used during the bootstrap and so its classes are not visible to Class.forName invocations made from the log4j.jar classes. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
