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]
