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 10: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. Sounds very reasonable. > 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. If I undestand correctly, the bootstrap server will load a simple log4j config, create a URLClassLoader, and reconconfigure log4j with a more sophisticated configuration loaded by the URLClassLoader. Is that correct? Now, assuming the TCL was set to the URLClassLoader, if log4j configurators used the TCL to load and instantiate classes by name, this would also work for you. Yes? Thus, we have three alternatives. 1) Log4j configurators use the class loader specified by the user, as you just suggested. 2) Log4j configurators use the TCL as a first alternative and only then Class.forName. 3) Use the CL specified by the user. If none is specified, revert to 2. I am inclined to offer just 2 immediately and 3 at a later stage. Would that be good enough for you? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
