[jcifs] FAQ - Samba Required on Client?

Eric Glass eric.glass at gmail.com
Mon Jul 19 23:35:11 GMT 2004

> >
> > I have read that doc over multiple times today and I'm confused as to what
> > I didn't do right.  I used the first example that shows how to specify a
> > WINS server, except in our situation, people will log on from multiple
> > domains so I didn't specify a domain.
> Nowhere does it say that jcifs.smb.client.domain is optional. Indeed it is
> not.

You would need to either specify "jcifs.smb.client.domain" or
"jcifs.http.domainController".  "jcifs.smb.client.domain" would be the
preferred method; jCIFS will look up a domain controller for the
domain specified.  You can log in with an account from any domain
trusted by that domain (chances are trusts are set up appropriately
already by your network administrators). 
"jcifs.http.domainController" is an IP address for a CIFS server (not
necessarily a domain controller, any Samba or Windows server running
CIFS/SMB services will work).

> > The documentation was a bit sketchy on whether the JAR file should be
> > placed in the Web Server's LIB directory instead of the web application
> > LIB directory.  When I tried to move it to the $JBOSS_HOME\lib directory,
> > my application failed to deploy giving errors that various SMBxxx classes
> > could not be found.
> The SMB protocol handler must be loaded by the system class loader. If the
> webapp lib directory is insufficent then that is something that would be
> specific to JBOSS.

The system class loader is required to register the SMB protocol
handler, but not to run the filter; under Tomcat, the filter actually
won't work with the handler registered (it will cause classpath
issues).  The filter should work fine with jCIFS under the web app's

The classpath issue arises because of the classloader architecture
used by many containers (and recommended by the servlet spec).  The
core servlet classes are in a child classloader of the system
classloader; each web application is in its own classloader which is a
child of the container loader.  Problems typically occur with the
filter if you load jCIFS under the system loader, because the filter
class then can't find its superclass (javax.servlet.Filter, which is
now in a child loader relative to the subclass).


More information about the jcifs mailing list