[jcifs] More classloader issues

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Glass, Eric [SMTP:eric.glass at capitalone.com]
> Sent:	Thursday, December 12, 2002 7:45 AM
> To:	'jcifs at lists.samba.org'
> Subject:	[jcifs] More classloader issues
> 
> Ok.  Installing jCIFS as an extension (or otherwise available to the system
> classloader) will resolve the issue with SMB URLs.  However, when you
> attempt to use NtlmFilter, you get:
> 
> java.lang.NoClassDefFoundError: javax/servlet/Filter
> 
> This is caused by the fact that NtlmFilter is now installed under the system
> classloader, while the core servlet classes are under the servlet
> container's classloader; since NtlmFilter is being loaded by the system
> classloader, it can no longer access its own superclass.  What this implies
> is that when the SMB URL support classes are properly installed and
> available, the NtlmFilter is not.
> 
> The only way I was able to get a servlet/JSP which uses SMB URLs working
> under the NtlmFilter was to amend build.xml to create 2 jars;
> 
	The "only way"? Putting it in the container's CLASSPATH works. At least with
	Resin it does. I have Resin running NetworkExplorer servlet at work which uses
	the NtlmHttpFilter and the NtlmPasswordAuthentication object returned by it to
	access SmbFile resources. I put the jar in the top-level resin lib directory.

>  one contains
> the core jCIFS classes (and should be installed as an extension or otherwise
> under the system classloader).  The other contains the http stuff, and
> should be installed under the web application classloader (i.e., in
> WEB-INF/lib).
> 
	I don't want to break up the package unnecessarily. If someone has permission
	to add the jar to the jre/lib/ext directory that implies they have permission to add
	it to the container CLASSPATH.

	So the solution to both the class loader and security policy issues is to just make
	sure that the jCIFS jar is in the container's CLASSPATH. Presumably these
	security policy files are associated with files loaded by web apps rather than the
	container itself. Right?

	Incedentally the Java version issue is really a separate issue. Even if some users
	that are getting the "unknown protocol: smb" exception are using an inadequate
	version of Java, that is coincidental. Just doing a simple test, what most users will
	see if they are using 1.2 or below is:

	jcifs-0.7.0b4+ requires Java 1.3 or above. You are running 1.2.2
	Exception in thread "main" java.lang.NoSuchMethodError: java.net.URL: method getAuthority()Ljava/lang/String; not found
	        at jcifs.smb.Handler.parseURL(Handler.java:52)
	        at java.net.URL.<init>(Compiled Code)
	        at java.net.URL.<init>(URL.java:364)
	        at java.net.URL.<init>(URL.java:308)
	        at jcifs.smb.SmbFile.<init>(SmbFile.java:355)
	        ...