You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Vasily Zakharov (JIRA)" <ji...@apache.org> on 2007/03/15 03:15:09 UTC
[jira] Created: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
[classlib][swing] UIDefaults.getUIClass() uses wrong classloader
----------------------------------------------------------------
Key: HARMONY-3398
URL: https://issues.apache.org/jira/browse/HARMONY-3398
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vasily Zakharov
For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
Returns: the Class object returned by getUIClass(uiClassID, null)
Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution.
The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3398:
-------------------------------------
Attachment: Harmony-3398-test.patch
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Attachments: Harmony-3398-fix.patch, Harmony-3398-test.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3398:
-------------------------------------
Attachment: Harmony-3398-fix.patch
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Attachments: Harmony-3398-fix.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov closed HARMONY-3398.
------------------------------------
Thanks, Alexey, the patch applied fine.
Verified, closing.
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Alexey Petrenko
> Attachments: Harmony-3398-fix.patch, Harmony-3398-test.patch, Harmony-3398-test.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Alexey Petrenko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Petrenko resolved HARMONY-3398.
--------------------------------------
Resolution: Fixed
The patch has been applied.
Please verify.
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Alexey Petrenko
> Attachments: Harmony-3398-fix.patch, Harmony-3398-test.patch, Harmony-3398-test.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3398:
-------------------------------------
Description:
For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
Returns: the Class object returned by getUIClass(uiClassID, null)
Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
This issue was discovered while investigating issue HARMONY-3385.
was:
For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
Returns: the Class object returned by getUIClass(uiClassID, null)
Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution.
The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
This issue was discovered while investigating issue HARMONY-3385.
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Attachments: Harmony-3398-fix.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3398) [classlib][swing]
UIDefaults.getUIClass() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3398:
-------------------------------------
Attachment: Harmony-3398-test.patch
Updated test patch.
> [classlib][swing] UIDefaults.getUIClass() uses wrong classloader
> ----------------------------------------------------------------
>
> Key: HARMONY-3398
> URL: https://issues.apache.org/jira/browse/HARMONY-3398
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Attachments: Harmony-3398-fix.patch, Harmony-3398-test.patch, Harmony-3398-test.patch
>
>
> For now getUIClass(String) uses ClassLoader.getSystemClassLoader() while it should pass null to getUIClass(String, ClassLoader) instead, as the spec states:
> Returns: the Class object returned by getUIClass(uiClassID, null)
> Also, getUIClass(String, ClassLoader), if passed null classloader, now passes that null to class.forName(), which makes third-party classes loaded by non-system classloader unavailable for this method. It looks like using Thread.currentThread().getContextClassLoader() instead is a proper solution. Reasons for using "false" in Class.forName() are also unclear.
> The test in the attached test patch passes on RI but fails on Harmony, and works fine after the attached fix patch is applied.
> This issue was discovered while investigating issue HARMONY-3385.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.