[Top][All Lists]
[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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bugs #9466] java.net.URL.getURLStreamHandler uses wrong classloader,
Mark Wielaard <=