[jcifs] smb protocol handler

[Glass, Eric]

I would concur with this recommendation -- providing the URLStreamHandler in
the constructor will prevent the URL class from searching for a handler
(which causes the ClassNotFound and MalformedURLExceptions under Tomcat).

Explicit registration of the handler also allows those that are simply using
the NTLM authentication pieces to bypass configuration of system properties,
etc. without worrying about causing exceptions in the static init block of
Config.  This also has the advantage that any exceptions that do occur can
be thrown from the registration method, rather than being thrown from the
static init block (where they prevent proper startup) or being suppressed
completely (where the handler ends up not being available).

> -----Original Message-----
> From: Marc Hoffmann [mailto:marc.hoffmann at mountainminds.com]
> Sent: Tuesday, December 24, 2002 7:35 AM
> To: jcifs at lists.samba.org
> Subject: [jcifs] smb protocol handler
> 
> 
> 
> Hi Mike,
> 
> my name is Marc Hoffmann, working with Fujitsu EST GmbH, 
> located in Munich.
> The company uses JCIFS for a while internally in one of their 
> Java APIs (see
> conversation with Uwe Specht regarding closed pipes).
> 
> 
> PROBLEM
> 
> The new URL design of version 0.7 introduces Java's powerful extension
> mechanism for new protocol types, but has also a serious 
> impact on system
> properties and class loading (see e.g. 
> "MalformedURLException" threads).
> Especially in the context of application servers this adds deployment
> hassles. Moreover, if necessary modifications of the security 
> settings or
> system libraries are not possible this could become a "show stopper".
> 
> 
> SUGGESTION
> 
> Therefore I would like to suggest making the registration of 
> the URL handler
> optional. It could explicitly triggered by an application by 
> invoking a
> static method like "Config.registerSmbURLHandler()".
> 
> To grant backward capability (concerning deployment) and 
> allow standard
> deployment of e.g. web applications the internal JCIFS 
> implementation should
> not rely on the registration of an URLStreamHandler.
> 
> 
> IMPLEMENTATION
> 
> The 0.7.0b10 implementation could easily be changed to work 
> without the need
> of the registered smb protocol. The basic idea is to 
> explicitly pass the
> proper URLStreamHandler directly to the internally used java.net.URL
> constructors. Some testing proofed that the 
> MalformedURLException does not
> happen, even if no system property is set and the jcifs.jar 
> is located in
> the WEB-INF/lib of a web application only.
> 
> I made the following modifications (source files attached):
> 
> 1. Provide an internally used singleton instance of jcifs.smb.Handler:
> 
>   static final URLStreamHandler SMB_HANDLER = new Handler();
> 
> 2. Replace all URL constructors in SmbFile with the URL(URL 
> context, String
> spec, URLStreamHandler handler) version, e.g.
> 
>     public SmbFile( SmbFile context, String name ) throws
> MalformedURLException, UnknownHostException {
>         this( context.isWorkgroup0() ?
>             new URL(null, "smb://" + name, Handler.SMB_HANDLER) :
>             new URL( context.url, name, Handler.SMB_HANDLER),
> context.auth );
>     }
> 
> 3. In the files SmbFileInputStream, SmbFileOutputStream, SmbNamedPipe
> replace "new SmbFile(new URL(urlstring))" by "new SmbFile(urlstring)".
> 
> This modification would certainly avoid many error 
> situations, especially
> for users who upgrade from older jcifs versions and do not 
> use java.net.URL
> to identify resources at all.
> 
> Best Regards,
> marc
> 
 
**************************************************************************
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.