commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #9466] java.net.URL.getURLStreamHandler uses wrong classloader


From: Mark Wielaard
Subject: [bugs #9466] java.net.URL.getURLStreamHandler uses wrong classloader
Date: Thu, 01 Jul 2004 18:54:34 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Galeon/1.3.15 (Debian package 1.3.15-2)

This mail is an automated notification from the bugs tracker
 of the project: classpath.

/**************************************************************************/
[bugs #9466] Latest Modifications:

Changes by: 
                Mark Wielaard <address@hidden>
'Date: 
                Thu 07/01/04 at 22:52 (Europe/Amsterdam)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | mark


------------------ Additional Follow-up Comments ----------------------------
Agreed that using the bootstrap classloader is probably not what you want. But 
I could not find which class loader strategy is actually expected. There are 
several options:
- Use the system/application ClassLoader
- Use the classloader of the first calling class that has a non-system 
classloader, using SecurityManager.currentClassLoader().
- Use the Thread context class loader.

For now I just implemented using the application/system classloader always 
since this class has been there since 1.0:

2004-07-01  Mark Wielaard  <address@hidden>

        * java/net/URL.java (systemClassLoader): New static field.
        (getURLStreamHandler): Always use system/application classloader
        for finding URLStreamhandler. Remove unecessary instanceof checks.

Could you check that this solves your problem?

An explicit testcase for Mauve is also highly appreciated.

Thanks,

Mark






/**************************************************************************/
[bugs #9466] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9466>
Project: classpath
Submitted by: David Holmes
On: Sat 06/26/04 at 18:51

Severity:  5 - Average
Resolution:  None
Assigned to:  mark
Status:  Open
Platform Version:  None


Summary:  java.net.URL.getURLStreamHandler uses wrong classloader

Original Submission:  The java.net.URL.getURLStreamHandler method tries to loan 
a potentially application-defined class using Class.forName(clsName). This will 
fail unless the specified class can be loaded by the bootstrap loader.

The correct behaviour would be to use the context class loader to load the 
class. At a minimum the system/application class loader must be used.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Thu 07/01/04 at 22:52         By: mark
Agreed that using the bootstrap classloader is probably not what you want. But 
I could not find which class loader strategy is actually expected. There are 
several options:
- Use the system/application ClassLoader
- Use the classloader of the first calling class that has a non-system 
classloader, using SecurityManager.currentClassLoader().
- Use the Thread context class loader.

For now I just implemented using the application/system classloader always 
since this class has been there since 1.0:

2004-07-01  Mark Wielaard  <address@hidden>

        * java/net/URL.java (systemClassLoader): New static field.
        (getURLStreamHandler): Always use system/application classloader
        for finding URLStreamhandler. Remove unecessary instanceof checks.

Could you check that this solves your problem?

An explicit testcase for Mauve is also highly appreciated.

Thanks,

Mark












For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9466>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]