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

Reply via email to