Hi,
On Sun, 2005-01-16 at 21:31 -0500, Steven Augart wrote:
Well, we're trying to make sure that we can set up an instance of URL
and URLClassLoader in two often-independent cases:
(1) boot time and
(2) after boot, if the context class loader (or one of its ancestors)
is some
Hi,
On Sat, 2005-01-15 at 22:55 -0500, Steven Augart wrote:
When we're at the phase in the bootstrap process where we are
generating the application class loader, the current context
loader is the bootstrap class loader. If URLClassLoader would use
only the bootstrap class loader, everything
Mark Wielaard wrote:
Note, that I already agree we should change to use the context
classloader (and the application classloader as backup if loading
through the context classloader fails and it isn't the same as the
application classloader). I just didn't make time to implement it.
I should have
Steven Augart wrote:
I have what I think is a strong argument for why we need to
use the context classloader.
What if someone is attempting to use the URL class in writing
their Application Class Loader (also known as the system class
loader)? We get a serious recursion and bootstrap
Mark Wielaard wrote:
Hi,
On Sun, 2005-01-16 at 10:09 -0500, Steven Augart wrote:
I don't think we should use the application classloader as backup
in every case. Remember, the application class loader may not be
available or working at this phase in the booting process
-- and it won't be if
Steven Augart writes:
If every context class loader were guaranteed to delegate upward first,
then we'd have no reason to put in the backup plan (delegate to the system
class loader) at all.
I'm a little rusty on the overall situation - despite submitting the bug
report :) I believe the
Mark Wielaard wrote:
Hi,
On Sat, 2005-01-01 at 16:01 +0100, Ewout Prangsma wrote:
Now; currently the URL class uses the system classloader to load
protocol handlers.
Must this really be the system classloader?
I have a protocol handler that is accessible via the context classloader
Hi,
On Sat, 2005-01-01 at 16:01 +0100, Ewout Prangsma wrote:
Now; currently the URL class uses the system classloader to load
protocol handlers.
Must this really be the system classloader?
I have a protocol handler that is accessible via the context classloader
Hi all,
First of all happy new year!
Now; currently the URL class uses the system classloader to load
protocol handlers.
Must this really be the system classloader?
I have a protocol handler that is accessible via the context classloader
(Thread.currentThread().getContextClassLoader()), but not
9 matches
Mail list logo
