P3
> > > > > Date: Wed, 28 Oct 1998 18:55:21 -0800
> > > > > From: Rich Kadel <###@###.###>
> > > > > X-Accept-Language: en
> > > > > MIME-Version: 1.0
> > > > > To: ###@###.###,
> > > > > ###@###.###
> > > > > Subject: Re: Can't add URLStreamHandlers from Java Plugin
> > > > > Content-Transfer-Encoding: 7bit
> > > > >
> > > > > Sorry to resend this, but this is a serious bug, and is still not fixed in
> > > > > the Release Candidate 1.
> > > > >
> > > > > I CANNOT run my software under the JDK 1.2 Java Plugin without deploying
> > my
> > > > > own, modified, version of rt.jar. Additional URLStreamHandlers won't load
> > > > > unless they are included in rt.jar. (Works fine as an application, but
> > not
> > > > > under the Java Plugin.)
> > > > >
> > > > > I also submitted this to the JDK bugs page a month ago, but can't find it
> > > > > when I search for the report in the bug database.
> > > > >
> > > > > Please let me know what the status is. (I'm worried that you aren't
> > > > > planning to fix it. Should I be concerned?)
> > > > >
> > > > > I'd love to discuss the problem with someone over the phone, if you like,
> > > > > and why it is EXTREMELY important.
> > > > >
> > > > > The details are once again included below.
> > > > >
> > > > > Thanks,
> > > > > Rich
> > > > > --
> > > > >
> > > > > On 29 September 1998, Rich Kadel wrote:
> > > > >
> > > > > > This appears to be a problem with all versions of the Java Plugin
> > > > > > (including JDK 1.1 and 1.2). (We're having trouble with the latest
> > > > > > version of the plugin for JDK 1.2 beta 4.2, but it still happens for
> > > > > > recent ones and I don't see any related bug reports--I'm assuming it's
> > > > > > not fixed.) I guess it is a Security restriction that we can't
> > > > > > override, and this is bad for us. Details are below, but in short, the
> > > > > > method URL.getURLStreamHandler() will not load a URLStreamHandler from
> > > > > > another Jar file, even if the System property
> > > > > > "java.protocol.handler.pkgs" is correctly set to include the right
> > > > > > package prefixes.
> > > > > >
> > > > > > We have our own URL called "filefactory" so we can open files from any
> > > > > > location (local, remote, or from a relative path) using a filefactory
> > > > > > URL like so:
> > > > > >
> > > > > > filefactory:///kadel/myprefs/TextEditor.pref
> > > > > > filefactory://remotehost/kadel/myprefs/TextEditor.pref
> > > > > >
> > > > > > It is a special kind of URL that goes through our FileFactory classes.
> > > > > > And to use it requires that we install our own URLStreamHandler.
> > > > > >
> > > > > > There are two ways to add a URLStreamHandler:
> > > > > >
> > > > > > 1. Install a URLStreamHandlerFactory by calling
> > > > > > URL.setURLStreamHandlerFactory(). This can be called only one
> > > > > > time, and the JavaPlugin has already done it. So we are out of
> > > > > > luck there.
> > > > > > 2. Set the System property "java.protocol.handler.pkgs" to include a
> > > > > > package prefix for your own protocols (vertical bar separated list
> > > > > > of paths), so if that property includes "com.dtai.protocols", then
> > > > > > there would be a class "com.dtai.protocols.filefactory.Handler".
> > > > > > This is what we did.
> > > > > >
> > > > > > So we changed the system property (which we could do because we signed
> > > > > > our Jar file), and added that path to it. As an unrestricted
> > > > > > application this worked fine. But in the PlugIn, it did not work!
> > > > > >
> > > > > > If we add our URLStreamHandler to the JavaPlugin's rt.jar file instead
> > > > > > (which we don't want to do, of course), then it actually works.
> > > > > >
> > > > > > We did some checking and found that the URL.getURLStreamHandler() method
> > > > > > does try to load our class "com.dtai.leif.protocol.filefactory.Handler"
> > > > > > (which succeeds outside of the JavaPlugin), but in a JavaPlugin it gets
> > > > > > a ClassNotFoundException!
> > > > > >
> > > > > > So the problem is that the JavaPlugin will not load a URLStreamHandler
> > > > > > from another Jar file.
> > > > > >
> > > > >
> > > > > From: Rich Kadel <###@###.###>
> > > > > X-Accept-Language: en
> > > > > MIME-Version: 1.0
> > > > > To: ###@###.###,
> > > > > ###@###.###
> > > > > Subject: Re: Can't add URLStreamHandlers from Java Plugin
> > > > > Content-Transfer-Encoding: 7bit
> > > > >
> > > > > Sorry to resend this, but this is a serious bug, and is still not fixed in
> > > > > the Release Candidate 1.
> > > > >
> > > > > I CANNOT run my software under the JDK 1.2 Java Plugin without deploying
> > my
> > > > > own, modified, version of rt.jar. Additional URLStreamHandlers won't load
> > > > > unless they are included in rt.jar. (Works fine as an application, but
> > not
> > > > > under the Java Plugin.)
> > > > >
> > > > > I also submitted this to the JDK bugs page a month ago, but can't find it
> > > > > when I search for the report in the bug database.
> > > > >
> > > > > Please let me know what the status is. (I'm worried that you aren't
> > > > > planning to fix it. Should I be concerned?)
> > > > >
> > > > > I'd love to discuss the problem with someone over the phone, if you like,
> > > > > and why it is EXTREMELY important.
> > > > >
> > > > > The details are once again included below.
> > > > >
> > > > > Thanks,
> > > > > Rich
> > > > > --
> > > > >
> > > > > On 29 September 1998, Rich Kadel wrote:
> > > > >
> > > > > > This appears to be a problem with all versions of the Java Plugin
> > > > > > (including JDK 1.1 and 1.2). (We're having trouble with the latest
> > > > > > version of the plugin for JDK 1.2 beta 4.2, but it still happens for
> > > > > > recent ones and I don't see any related bug reports--I'm assuming it's
> > > > > > not fixed.) I guess it is a Security restriction that we can't
> > > > > > override, and this is bad for us. Details are below, but in short, the
> > > > > > method URL.getURLStreamHandler() will not load a URLStreamHandler from
> > > > > > another Jar file, even if the System property
> > > > > > "java.protocol.handler.pkgs" is correctly set to include the right
> > > > > > package prefixes.
> > > > > >
> > > > > > We have our own URL called "filefactory" so we can open files from any
> > > > > > location (local, remote, or from a relative path) using a filefactory
> > > > > > URL like so:
> > > > > >
> > > > > > filefactory:///kadel/myprefs/TextEditor.pref
> > > > > > filefactory://remotehost/kadel/myprefs/TextEditor.pref
> > > > > >
> > > > > > It is a special kind of URL that goes through our FileFactory classes.
> > > > > > And to use it requires that we install our own URLStreamHandler.
> > > > > >
> > > > > > There are two ways to add a URLStreamHandler:
> > > > > >
> > > > > > 1. Install a URLStreamHandlerFactory by calling
> > > > > > URL.setURLStreamHandlerFactory(). This can be called only one
> > > > > > time, and the JavaPlugin has already done it. So we are out of
> > > > > > luck there.
> > > > > > 2. Set the System property "java.protocol.handler.pkgs" to include a
> > > > > > package prefix for your own protocols (vertical bar separated list
> > > > > > of paths), so if that property includes "com.dtai.protocols", then
> > > > > > there would be a class "com.dtai.protocols.filefactory.Handler".
> > > > > > This is what we did.
> > > > > >
> > > > > > So we changed the system property (which we could do because we signed
> > > > > > our Jar file), and added that path to it. As an unrestricted
> > > > > > application this worked fine. But in the PlugIn, it did not work!
> > > > > >
> > > > > > If we add our URLStreamHandler to the JavaPlugin's rt.jar file instead
> > > > > > (which we don't want to do, of course), then it actually works.
> > > > > >
> > > > > > We did some checking and found that the URL.getURLStreamHandler() method
> > > > > > does try to load our class "com.dtai.leif.protocol.filefactory.Handler"
> > > > > > (which succeeds outside of the JavaPlugin), but in a JavaPlugin it gets
> > > > > > a ClassNotFoundException!
> > > > > >
> > > > > > So the problem is that the JavaPlugin will not load a URLStreamHandler
> > > > > > from another Jar file.
> > > > > >
> > > > >