[jcifs] smb protocol handler

[Michael B. Allen]

Ok, we'll give it a whirl. Also does the 'Using Weblogic 6.1' message
from Carson Gross look like something we want in?

On Thu, 26 Dec 2002 07:53:11 -0500
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> 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.


-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.