[jcifs] More classloader issues

[Glass, Eric]

> 	Ok. I didn't understand this. I thought (hoped) each 
> class would be loaded using
> 	some kind of static "context" based on the initial 
> class that would re-evaluate the
> 	hierarchy of classloaders.
> 

That is actually what Thread.getContextClassLoader() is for (to provide a
context from which to load classes and resources); however, it appears to be
targeted for use by application-level code rather than at a system level.
When actually defining the jcifs.http.NtlmFilter class, the classloading
mechanism loads the bytes from the .class file and calls the final method:

ClassLoader.defineClass(String name, byte[] b, int off, int len,
ProtectionDomain protectionDomain)

The ProtectionDomain object encapsulates information about the origin of the
class, including the location from which it was loaded and the classloader
"owning" that domain; when attempting to access the superclass
javax.servlet.Filter, this is the classloader which is used to initiate the
search.  I'm not sure why the context classloader isn't used -- I can only
guess that it either

a) poses a security concern of some sort;
b) breaks existing code (the context classloader wasn't introduced until
1.2); or (the most likely reason)
c) may cause confusion in subsequent classloading operations -- typically,
classloaders cache classes after loading them the first time; using the
thread context classloader would subvert the normal classloader hierarchy.
Subsequent attempts to load a class from a different thread (with a
different context classloader) could conceivably access resources from an
entirely unrelated codesource which would not normally be visible.

> > 
> 	Well we cannot just put the regular jar in the webapp 
> WEB-INF/lib because of
> 	the PropertyPermission issue

Actually, the PropertyPermission issue is a fairly minor one; most
containers (standalone Tomcat included) don't enforce any security policy
unless explicitly told to.  The issue preventing the jCIFS jar from residing
in the WEB-INF/lib directory is the need for the URL class to load
jcifs.smb.Handler from the system classloader.

> but perhaps, just for Tomcat users, we can just
> 	create an extra "jcifstomcat.jar" that has just the 
> jcifs.http package for putting
> 	in WEB-INF/lib directory of the web app. The regular 
> jar would be left alone and
> 	will also contain the jcifs.http package. Does that 
> sound feasable?
> 

I actually attempted this earlier; now you get into a semantically sticky
area.  According to the servlet spec:

"It is recommended also that the application class loader be implemented so
that classes and resources packaged within the WAR are loaded in preference
to classes and resources residing in container-wide library JARs."

This is satisfied in Tomcat by loading classes from the web application
classloader before attempting to load from the shared or common
classloaders.  However, the spec also states:

"It must not allow the WAR to override J2SE or Java servlet API classes."

Tomcat satisfies this requirement as follows (from
org.apache.catalina.loader.WebappClassLoader):


// (0.2) Try loading the class with the system class loader, to prevent
//       the webapp from overriding J2SE classes
try {
    clazz = system.loadClass(name);
    if (clazz != null) {
        if (resolve)
            resolveClass(clazz);
        return (clazz);
    }
} catch (ClassNotFoundException e) {
    // Ignore
}


So if jcifs.http.NtlmFilter is placed in both the system AND webapp class
paths, it will be loaded by the system classloader (somewhat
counterintuitively, and contradictory to Tomcat's documentation on
classloading at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html).
I'm not sure if this is technically a bug, in that this implementation does
satisfy the spec -- J2SE and Servlet API classes cannot be overridden by web
applications.  It just doesn't work in our case because the servlet API
classes aren't visible to the system classloader.

Eric
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.