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=5391>. 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=5391 Can't change the ClassLoader for WebappLoader using loaderClass [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] Status|RESOLVED |REOPENED Resolution|FIXED | Version|4.0.1 Final |4.0.2 Final ------- Additional Comments From [EMAIL PROTECTED] 2002-02-17 03:42 ------- The reported bug still exists. In fact, the method setLoaderClass() in the WebappLoader code has been fixed and works in Tomcat 4.0.2. However, the start() method makes no use of the value set in the 'loaderClass' variable and instead it still contains a hard wired piece of code, which creates an instance of 'WebappClassLoader'. Code fragment of start()-method beeing in charge: ... if (parentClassLoader == null) { classLoader = new WebappClassLoader(container.getResources()); } else { classLoader = new WebappClassLoader (parentClassLoader, container.getResources()); } ... To make things work, we should rather use dynamic class loading (parametrized with 'loaderClass' member variable) at this point. The code fragment might look like this: ... if (parentClassLoader == null) { Class params[] = { DirContext.class }; Constructor constructor = cl.getConstructor(params); Object initargs[] = { container.getResources() }; classLoader = (WebappClassLoader) constructor.newInstance(initargs); } else { Class params[] = { ClassLoader.class, DirContext.class }; Constructor constructor = cl.getConstructor(params); Object initargs[] = { parentClassLoader, container.getResources() }; classLoader = (WebappClassLoader) constructor.newInstance(initargs); } ... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>