Name: nt126004 Date: 03/03/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows NT Version 4.0

A DESCRIPTION OF THE PROBLEM :
The package method: URL.getURLStreamHandler(String name)
tries to load handler classes using only the class loader
of the URL class or the System class loader and dosen't try
with the context class loader. This means that all handler
classes have to be loaded from the System class loader or
the bootstracp class loader.

However if this is the intended functionality the JavaDocs
should be updated to reflect this.

I've been playing around with custom classloaders for The Community OpenORB
project where previously we simply used the standard system class loader.

OpenORB uses two customized URL protocols "resource" and "classpath". We started
having problems reading such URL's when using the custom class loaders as the
Handler classes were no longer loadable from the system class loader. By using
URL.setURLStreamHandlerFactory we could avoid this issue but this causes
problems if the ORB is used inside of a container which might have installed its
own factory. By using the thread context class loader, the URL class could load
its Handler classes from a greater range of sources.

However there are possible issues due to the way that handlers are cached once
instantiated:

1. As all loaded handlers are reachable via a static field of a class loaded by
the system class loader, they are never garbage collected. As the object is
never gc'd the class loader of the objects class is never gc'd either. This
could cause a gradual memory leak especially if there is a lot of static data
held in the classes loade by the classloader.

2. The new resource handler is a system wide customization and might interfere
with over components.

Issue 1 could be solved by using WeakReferences, however issue 2 still causes
problems. I've though of three possible solutions to the problem:

1. Don't cache the protocol handlers when loaded from the context class loader.

2. Add another set of URL constructors that take a URLStreamHandlerFactory so
that components can be configured with a factory to use and don't have to
pre-parse the URL String to see which handler to use. This would be nice but
requires a change to the API.

3. Cache protocol handlers loaded from the context class loader on a per class
loader basis. The handlers are found by searching the delegation hierachy of the
context class loader for cached values.


REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 181608)
======================================================================