[jcifs] More classloader issues

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Mon Dec 16 10:38:47 EST 2002

> -----Original Message-----
> From:	Glass, Eric [SMTP:eric.glass at capitalone.com]
> > > The problem will arise under Tomcat when NtlmFilter is 
> > loaded; it will find
> > > the implementation under the system classloader, but 
> > NtlmFilter will be
> > > unable to find javax.servlet.Filter (which is loaded under 
> > the common
> > > classloader).  This will cause a NoClassDefFoundError, specifically:
> > 
> > But the container will be trying to load classes in the Webapp class
> > loader. So when accessing jcifs.http.NtlmHttpFilter it will fail as it
> > will in the Shared and Common class loaders before 
> > successfully loading
> > from the System class loader. Now when resolving the 
> > javax.servlet.Filter
> > baseclass and other servlet classes will it try from the Webapp
> > classloader again or degenerate to the classloader from which it just
> > loaded jcifs.http.NtlmHttpFilter? I don't see the security risk in
> > starting from the original context loader again.
> It's not as much a matter of security as it is visibility; what happens is:

> f) As part of the class definition process, the system classloader attempts
> to locate and load the superclass (javax.servlet.Filter).  This process is
> independent of the loading of NtlmHttpFilter; the system classloader is
> unaware of the existence of the descendant classloaders (common, shared, and
> webapp).  Since the system classloader is the defining classloader for
	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.

> NtlmHttpFilter, that is where the search begins (and, as it turns out, ends
> with a failure).
> This is kind of a simplification; in reality only the webapp classloader
> attempts to load the class before delegating to the parent (the normal JDK
> behavior is to delegate to the parent first, and load the class only if the
> parent cannot find it; the servlet spec reverses this behavior for the
> webapp classloader to allow web applications to override container-wide
> classes).  But the end result is the same; webapp fails, and delegates to
> shared, which delegates to common, which delegates to system, which
> succeeds.  While defining the NtlmHttpFilter class, system attempts to load
> javax.servlet.Filter, and fails.
> Basically each classloader is only aware of its parent, and has no means of
> knowing if any child classloaders exist.
> > 
> > Also getting jcifs.smb.Handler installed in the System class loader is
> > a completely separate issue right? There's really no relation between
> > the problems other than their both being "class loading" issues.
> > 
> That is correct, with the caveat being that putting jcifs.smb.Handler in the
> system classloader also puts NtlmHttpFilter in the system classloader (since
> they are packaged together), which causes the Tomcat issue.  To resolve it,
> Tomcat users have to make sure that the core servlet classes are available
> in either the same classloader as jCIFS or an ancestor; this involves
> leaving jcifs.http.* under the webapp classloader (as a separate jar) or
> moving "servlet.jar" into the system classloader with the jCIFS jar.

> > I just need to establish the simplest "correct" installation 
> > procedure. So
> > far, ensuring the jar is loaded by the System class loader 
> > and that it's
> > codeBase has the necesary PropertyPermission should work. If 
> > anyone wants
> > a more finely grained procedure they can be referred to these messages
> > in the archive.
> > 
> Possibly a note for Tomcat users to relocate the servlet.jar, or a note to
> see the FAQ.  Other than that, this should suffice.
	Well we cannot just put the regular jar in the webapp WEB-INF/lib because of
	the PropertyPermission issue 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?

More information about the jcifs mailing list