Alex The light went on and I'm now wondering if I triggered this with the changes for deployment scanning.
IIRC the code used to generate new URLs from the File paths returned during the scan, basically using the URL(String) constructor with the path. It now creates URLs relative to the location being scanned using the URL(URL, String) version. The context URL is the one obtained from ServerConfig.getServerHomeURL(). If this is set before the custom handler factory is set up, then all deployed URLs would be using Sun's handler :-( I think this is happening because ServerImpl.doInit() creates the ServerConfigImpl before setting up the URLStreamHandlerFactory. Would it make sense just to move the factory set-up to the very start of doInit()? Jeremy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Alex > Loubyansky > Sent: Wednesday, January 15, 2003 5:21 AM > To: Scott M Stark > Subject: Re[6]: [JBoss-dev] URLConnection and opened files > > > Here are my findings. > > First, JBoss-3.0 is ok. The problem is in JBoss-3.2 and HEAD. > > Second, I found the cause. > The resources we want to load with our custom handlers > through class loaders must be added to the classpath AFTER the > (custom) URLStreamHandlerFactory is setup. > > URLClassLoaders hold their URLs. > The URLs created before the custom URLStreamHandlerFactory is set up > have Sun's handler. System class loader is a subclass of the > URLClassLoader. Thus, its URLs have Sun's handler. (It seems to me even > if java.protocol.handler.pkgs is setup. Is it a VM's bug or mine?) > > Suppose we attempt to load resource that was in the classpath before > the custom handler factory was setup. The URL for the resource is > constructed with: URL(URL context, String spec). > where the context URL comes from the class loader with Sun's handler. > Then resource's URL's handler is assigned context.handler. > So, it doesn't matter whether the custom handler factory is setup. > > alex > ------------------------------------------------------- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
