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/21 03:37:32 UTC
[jira] Created: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
[classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
------------------------------------------------------------------------------------
Key: HARMONY-3454
URL: https://issues.apache.org/jira/browse/HARMONY-3454
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Vasily Zakharov
Priority: Minor
Attachments: Test.java
Consider the attached test.
It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
Output on RI:
java.lang.NullPointerException
at java.util.Hashtable.put(Unknown Source)
at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
at Test$1ThreadCheckEditorKit.run(Test.java:33)
1: MyEditorKit@190d11 : ArrayClassLoader@19821f
2: MyEditorKit@a90653 : ArrayClassLoader@19821f
3: MyEditorKit@de6ced : ArrayClassLoader@42e816
4: MyEditorKit@c17164 : ArrayClassLoader@19821f
5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
6: MyEditorKit@61de33 : ArrayClassLoader@42e816
Output on Harmony:
1: null
2: null
3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
4: null
5: null
6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (HARMONY-3454) [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Ivanov, Alexey A" <al...@intel.com>.
Vasily, Nathan, all,
It is true that some of JEditorPane tests are failing now. They started
failing after HTML-related code in JEditorPane was uncommented, see
HARMONY-3192. A JIRA issue HARMONY-3202 has been created to fix the
test.
JEditorPaneTest.testSetGetPage1() fails due to trying to access
www.apache.org. Vasily, since you run this test behind firewall, the
server cannot be accessed. If you configure proxy settings for Java,
this test should pass. You can use the following command line arguments
to achieve this:
-Dhttp.proxyHost=<your proxy> -Dhttp.proxyPort=<proxy port>
-DproxySet=true
This test needs modifying to not depend on proxy setting. I guess it's
not necessary to access a remote server, a temporary file passed as URL
to JEditorPane.setPage will be quite enough.
I can't comment about other tests.
What I know for sure is Harmony HTML parser implementation is not
compatible with the RI one, which causes lots of HTML-related tests
(which are still completely disabled in Harmony) to fail, just because
the constructed HTML model is not as expected. I didn't have time to
thoroughly look at the tests though.
Regards,
Alexey.
Related links:
https://issues.apache.org/jira/browse/HARMONY-3192
https://issues.apache.org/jira/browse/HARMONY-3202
--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division
>-----Original Message-----
>From: Zakharov, Vasily M [mailto:vasily.m.zakharov@intel.com]
>Sent: Thursday, April 12, 2007 3:39 AM
>To: dev@harmony.apache.org
>Subject: RE: [jira] Commented: (HARMONY-3454) [classlib][swing]
>JEditorPane.createEditorKitForContentType() uses wrong classloader
>
>Nathan,
>
>I experience three stable failures of JEditorPane tests on my Windows
XP
>(32-bit).
>Details are below. The first one, clearly, is due to I'm behind a
>firewall and
>the test either doesn't support proxy or is not configured with my
>particular proxy
>location.
>
>JEditorPaneTest.testSetGetPage1():
>Unexpected exception :www.apache.org/140.211.11.130:80 - Socket is not
>connected
>junit.framework.AssertionFailedError: Unexpected exception
>:www.apache.org/140.211.11.130:80 - Socket is not connected at
>javax.swing.JEditorPaneTest.testSetGetPage1(JEditorPaneTest.java:558)
at
>java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
>javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117
)
>at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45) at
>java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92) at
>java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81) at
>java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:140) at
>java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
>java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74)
>at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>
>JEditorPane_MultithreadedTest.testSetGetTextHTML():
>javax.swing.text.html.parser.Lexer
>java.lang.NoClassDefFoundError: javax.swing.text.html.parser.Lexer at
>javax.swing.text.html.parser.Parser$ParserHandlerImpl.parse(Parser.java
:
>52) at javax.swing.text.html.parser.Parser.parse(Parser.java:399) at
>javax.swing.text.html.parser.DocumentParser.parse(DocumentParser.java:9
8
>) at
>javax.swing.text.html.parser.ParserDelegator.parse(ParserDelegator.java
:
>80) at javax.swing.text.html.HTMLEditorKit.read(HTMLEditorKit.java:736)
>at javax.swing.text.JTextComponent.read(JTextComponent.java:1289) at
>javax.swing.JEditorPane.setText(JEditorPane.java:772) at
>javax.swing.JEditorPane_MultithreadedTest.testSetGetTextHTML(JEditorPan
e
>_MultithreadedTest.java:22) at
>java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
>
>JEditorPane_AccessibleJEditorPaneHTMLTest.testGetAccessibleText():
>N/A
>org.apache.harmony.luni.util.NotImplementedException at
>javax.swing.JEditorPane$JEditorPaneAccessibleHypertextSupport.<init>(JE
d
>itorPane.java:159) at
>javax.swing.JEditorPane$AccessibleJEditorPaneHTML.getAccessibleText(JEd
i
>torPane.java:99) at
>javax.swing.JEditorPane_AccessibleJEditorPaneHTMLTest.testGetAccessible
T
>ext(JEditorPane_AccessibleJEditorPaneHTMLTest.java:50) at
>java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
>javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117
)
>at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45) at
>java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92) at
>java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81) at
>java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:140) at
>java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
>java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74)
>at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>
> Vasily
>
>
>-----Original Message-----
>From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
>Beyer
>Sent: Thursday, April 12, 2007 3:00 AM
>To: dev@harmony.apache.org
>Subject: Re: [jira] Commented: (HARMONY-3454) [classlib][swing]
>JEditorPane.createEditorKitForContentType() uses wrong classloader
>
>Is anyone having failures in JEditorPaneTest in the swing module? I
>removed some from the exclude, accidentally, but they are passing
>perfectly well on my Windows XP build of classlib on ibmvm.
>
>I see one of the linux builds failed on this test, so I'm wondering if
>the exclusion should be relegated to linux alone. Also, I'm curious
>why it would fail there.
>
>-Nathan
>
>On 4/11/07, Vasily Zakharov (JIRA) <ji...@apache.org> wrote:
>>
>> [
>https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.j
i
>ra.plugin.system.issuetabpanels:comment-tabpanel#action_12488128 ]
>>
>> Vasily Zakharov commented on HARMONY-3454:
>> ------------------------------------------
>>
>> The fix and test patches are fine, thanks Nathan.
>>
>> As of make patch, it was only attached for you to make sure the other
>patches do not break anything, and was not supposed to be committed, as
>I stated above when attaching it. Three test cases in the excluded
tests
>fail (including the one you mentioned above) on my machine, so probably
>it would be right to put those tests back to exclude list by rolling
the
>make patch back.
>>
>> Thank you!
>>
>>
>> > [classlib][swing] JEditorPane.createEditorKitForContentType() uses
>wrong classloader
>> >
>-----------------------------------------------------------------------
-
>------------
>> >
>> > Key: HARMONY-3454
>> > URL:
>https://issues.apache.org/jira/browse/HARMONY-3454
>> > Project: Harmony
>> > Issue Type: Bug
>> > Components: Classlib
>> > Reporter: Vasily Zakharov
>> > Assigned To: Nathan Beyer
>> > Priority: Minor
>> > Attachments: Harmony-3454-fix.patch,
Harmony-3454-fix.patch,
>Harmony-3454-fix.patch, Harmony-3454-fix.patch,
Harmony-3454-make.patch,
>Harmony-3454-test.patch, Test.java
>> >
>> >
>> > Consider the attached test.
>> > It creates a thread, sets a context classloader for it, and than
>calls registerEditorKitForContentType() with no classloader specified
>(1), null classloader (2) and another specific classloader (3). Then in
>the same thread it calls createEditorKitForContentType for all three
>registered content types (results 1, 2, 3). Next, it creates another
>thread, with default context classloader, in which again calls
>createEditorKitForContentType again for all three registered types
>(results 4, 5, 6).
>> > Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack
in
>the RI output are due to what I consider a bug in RI implementation
(see
>HARMONY-3453), and do not affect this issue effectively.
>> > Output on RI:
>> > java.lang.NullPointerException
>> > at java.util.Hashtable.put(Unknown Source)
>> > at
>javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
>> > at Test$1ThreadCheckEditorKit.run(Test.java:33)
>> > 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
>> > 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
>> > 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
>> > 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
>> > 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
>> > 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
>> > Output on Harmony:
>> > 1: null
>> > 2: null
>> > 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
>> > 4: null
>> > 5: null
>> > 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
>> > The null values in cases 1, 2, 4, 5 are due to Harmony
>implementation of createEditorKitForContentType() uses
>Class.forName(className) to load EditorKit classes, while it should use
>Class.forName(className, true,
>Thread.currentThread().getContextClassLoader()), as RI does (as may be
>seen clearly from the output above). This situation is very similar to
>HARMONY-3398 and HARMONY-3420.
>> > The test doesn't set a context class loader for the second thread,
>however, RI manages to create EditorKit instances in cases 4 and 5
>successfuly. This means that
>Thread.currentThread().getContextClassLoader() should be called not in
>createEditorKitForContentType(), but in
>registerEditorKitForContentType() instead, and the result should be put
>to the registration table.
>> > createEditorKitForContentType() may be left as it is, however, it's
>better be simplified to use Class.forName(kitName, true, loader) in all
>cases, which is equivalent to the current code. Also, catch statements
>in createEditorKitForContentType() are better be adjusted, as besides
>IllegalAccessException, ClassNotFoundException and
>InstantiationException, also LinkageError and ClassCastException may be
>thrown as well. It looks like catching Throwable is appropriate in this
>case.
>> > The attached patch addresses all the changes above.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
RE: [jira] Commented: (HARMONY-3454) [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Zakharov, Vasily M" <va...@intel.com>.
Nathan,
I experience three stable failures of JEditorPane tests on my Windows XP
(32-bit).
Details are below. The first one, clearly, is due to I'm behind a
firewall and
the test either doesn't support proxy or is not configured with my
particular proxy
location.
JEditorPaneTest.testSetGetPage1():
Unexpected exception :www.apache.org/140.211.11.130:80 - Socket is not
connected
junit.framework.AssertionFailedError: Unexpected exception
:www.apache.org/140.211.11.130:80 - Socket is not connected at
javax.swing.JEditorPaneTest.testSetGetPage1(JEditorPaneTest.java:558) at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92) at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:140) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
JEditorPane_MultithreadedTest.testSetGetTextHTML():
javax.swing.text.html.parser.Lexer
java.lang.NoClassDefFoundError: javax.swing.text.html.parser.Lexer at
javax.swing.text.html.parser.Parser$ParserHandlerImpl.parse(Parser.java:
52) at javax.swing.text.html.parser.Parser.parse(Parser.java:399) at
javax.swing.text.html.parser.DocumentParser.parse(DocumentParser.java:98
) at
javax.swing.text.html.parser.ParserDelegator.parse(ParserDelegator.java:
80) at javax.swing.text.html.HTMLEditorKit.read(HTMLEditorKit.java:736)
at javax.swing.text.JTextComponent.read(JTextComponent.java:1289) at
javax.swing.JEditorPane.setText(JEditorPane.java:772) at
javax.swing.JEditorPane_MultithreadedTest.testSetGetTextHTML(JEditorPane
_MultithreadedTest.java:22) at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
JEditorPane_AccessibleJEditorPaneHTMLTest.testGetAccessibleText():
N/A
org.apache.harmony.luni.util.NotImplementedException at
javax.swing.JEditorPane$JEditorPaneAccessibleHypertextSupport.<init>(JEd
itorPane.java:159) at
javax.swing.JEditorPane$AccessibleJEditorPaneHTML.getAccessibleText(JEdi
torPane.java:99) at
javax.swing.JEditorPane_AccessibleJEditorPaneHTMLTest.testGetAccessibleT
ext(JEditorPane_AccessibleJEditorPaneHTMLTest.java:50) at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117)
at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45) at
java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92) at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81) at
java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:140) at
java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at
java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
Vasily
-----Original Message-----
From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
Beyer
Sent: Thursday, April 12, 2007 3:00 AM
To: dev@harmony.apache.org
Subject: Re: [jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Is anyone having failures in JEditorPaneTest in the swing module? I
removed some from the exclude, accidentally, but they are passing
perfectly well on my Windows XP build of classlib on ibmvm.
I see one of the linux builds failed on this test, so I'm wondering if
the exclusion should be relegated to linux alone. Also, I'm curious
why it would fail there.
-Nathan
On 4/11/07, Vasily Zakharov (JIRA) <ji...@apache.org> wrote:
>
> [
https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.ji
ra.plugin.system.issuetabpanels:comment-tabpanel#action_12488128 ]
>
> Vasily Zakharov commented on HARMONY-3454:
> ------------------------------------------
>
> The fix and test patches are fine, thanks Nathan.
>
> As of make patch, it was only attached for you to make sure the other
patches do not break anything, and was not supposed to be committed, as
I stated above when attaching it. Three test cases in the excluded tests
fail (including the one you mentioned above) on my machine, so probably
it would be right to put those tests back to exclude list by rolling the
make patch back.
>
> Thank you!
>
>
> > [classlib][swing] JEditorPane.createEditorKitForContentType() uses
wrong classloader
> >
------------------------------------------------------------------------
------------
> >
> > Key: HARMONY-3454
> > URL:
https://issues.apache.org/jira/browse/HARMONY-3454
> > Project: Harmony
> > Issue Type: Bug
> > Components: Classlib
> > Reporter: Vasily Zakharov
> > Assigned To: Nathan Beyer
> > Priority: Minor
> > Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch,
Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch,
Harmony-3454-test.patch, Test.java
> >
> >
> > Consider the attached test.
> > It creates a thread, sets a context classloader for it, and than
calls registerEditorKitForContentType() with no classloader specified
(1), null classloader (2) and another specific classloader (3). Then in
the same thread it calls createEditorKitForContentType for all three
registered content types (results 1, 2, 3). Next, it creates another
thread, with default context classloader, in which again calls
createEditorKitForContentType again for all three registered types
(results 4, 5, 6).
> > Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in
the RI output are due to what I consider a bug in RI implementation (see
HARMONY-3453), and do not affect this issue effectively.
> > Output on RI:
> > java.lang.NullPointerException
> > at java.util.Hashtable.put(Unknown Source)
> > at
javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> > at Test$1ThreadCheckEditorKit.run(Test.java:33)
> > 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> > 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> > 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> > 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> > 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> > 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> > Output on Harmony:
> > 1: null
> > 2: null
> > 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> > 4: null
> > 5: null
> > 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> > The null values in cases 1, 2, 4, 5 are due to Harmony
implementation of createEditorKitForContentType() uses
Class.forName(className) to load EditorKit classes, while it should use
Class.forName(className, true,
Thread.currentThread().getContextClassLoader()), as RI does (as may be
seen clearly from the output above). This situation is very similar to
HARMONY-3398 and HARMONY-3420.
> > The test doesn't set a context class loader for the second thread,
however, RI manages to create EditorKit instances in cases 4 and 5
successfuly. This means that
Thread.currentThread().getContextClassLoader() should be called not in
createEditorKitForContentType(), but in
registerEditorKitForContentType() instead, and the result should be put
to the registration table.
> > createEditorKitForContentType() may be left as it is, however, it's
better be simplified to use Class.forName(kitName, true, loader) in all
cases, which is equivalent to the current code. Also, catch statements
in createEditorKitForContentType() are better be adjusted, as besides
IllegalAccessException, ClassNotFoundException and
InstantiationException, also LinkageError and ClassCastException may be
thrown as well. It looks like catching Throwable is appropriate in this
case.
> > The attached patch addresses all the changes above.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [jira] Commented: (HARMONY-3454) [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by Nathan Beyer <nd...@apache.org>.
Is anyone having failures in JEditorPaneTest in the swing module? I
removed some from the exclude, accidentally, but they are passing
perfectly well on my Windows XP build of classlib on ibmvm.
I see one of the linux builds failed on this test, so I'm wondering if
the exclusion should be relegated to linux alone. Also, I'm curious
why it would fail there.
-Nathan
On 4/11/07, Vasily Zakharov (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488128 ]
>
> Vasily Zakharov commented on HARMONY-3454:
> ------------------------------------------
>
> The fix and test patches are fine, thanks Nathan.
>
> As of make patch, it was only attached for you to make sure the other patches do not break anything, and was not supposed to be committed, as I stated above when attaching it. Three test cases in the excluded tests fail (including the one you mentioned above) on my machine, so probably it would be right to put those tests back to exclude list by rolling the make patch back.
>
> Thank you!
>
>
> > [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> > ------------------------------------------------------------------------------------
> >
> > Key: HARMONY-3454
> > URL: https://issues.apache.org/jira/browse/HARMONY-3454
> > Project: Harmony
> > Issue Type: Bug
> > Components: Classlib
> > Reporter: Vasily Zakharov
> > Assigned To: Nathan Beyer
> > Priority: Minor
> > Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
> >
> >
> > Consider the attached test.
> > It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> > Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> > Output on RI:
> > java.lang.NullPointerException
> > at java.util.Hashtable.put(Unknown Source)
> > at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> > at Test$1ThreadCheckEditorKit.run(Test.java:33)
> > 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> > 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> > 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> > 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> > 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> > 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> > Output on Harmony:
> > 1: null
> > 2: null
> > 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> > 4: null
> > 5: null
> > 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> > The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> > The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> > createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> > The attached patch addresses all the changes above.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Attachment: Harmony-3454-fix.patch
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Attachment: Harmony-3454-fix.patch
The updated patch is attached.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Attachment: Harmony-3454-make.patch
Harmony-3454-test.patch
Harmony-3454-fix.patch
Attached updated fix patch and a test patch.
Also attached a make patch that removes JEditorPane tests from make/exclude.common.
This patch probably should not be applied permanently as three tests there fail independently of this fix.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488117 ]
Nathan Beyer commented on HARMONY-3454:
---------------------------------------
I'm getting a test failure from one of the newly included tests. It's a NotImplementedException, so I suspect that this test really isn't ready to be included yet. I'll commit the patch without this test included for now.
N/A
org.apache.harmony.luni.util.NotImplementedException at javax.swing.JEditorPane$JEditorPaneAccessibleHypertextSupport.<init>(JEditorPane.java:159) at javax.swing.JEditorPane$AccessibleJEditorPaneHTML.getAccessibleText(JEditorPane.java:99) at javax.swing.JEditorPane_AccessibleJEditorPaneHTMLTest.testGetAccessibleText(JEditorPane_AccessibleJEditorPaneHTMLTest.java:50) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:117) at javax.swing.SwingTestCase$1.run(SwingTestCase.java:45) at java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:92) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:81) at java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:140) at java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:74) at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485519 ]
Vasily Zakharov commented on HARMONY-3454:
------------------------------------------
Please see HARMONY-3453 for the detailed discussion of the proposed fix for this issue.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Beyer closed HARMONY-3454.
---------------------------------
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Patch Info: [Patch Available]
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488128 ]
Vasily Zakharov commented on HARMONY-3454:
------------------------------------------
The fix and test patches are fine, thanks Nathan.
As of make patch, it was only attached for you to make sure the other patches do not break anything, and was not supposed to be committed, as I stated above when attaching it. Three test cases in the excluded tests fail (including the one you mentioned above) on my machine, so probably it would be right to put those tests back to exclude list by rolling the make patch back.
Thank you!
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Attachment: Harmony-3454-fix.patch
I've updated the fix patch according to the discussion in the dev list:
http://thread.gmane.org/gmane.comp.java.harmony.devel/25666
Nathan, please apply the patches.
Thank you!
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485942 ]
Alexey A. Ivanov commented on HARMONY-3454:
-------------------------------------------
Vasily,
It would be great if you added tests, at least the test case from HARMONY-3453. I haven't reviewed the patch thoroughly, so I can't insist new tests are needed.
I didn't like your localization in getEditorKitClassNameForContentType method. There's NPE thrown, and one part of the message would be localized whereas the other would not. Don't you think that localizing "Content type" string here and in similar places is a good idea?
Regards,
Alexey.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Beyer reassigned HARMONY-3454:
-------------------------------------
Assignee: Nathan Beyer
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483172 ]
Vasily Zakharov commented on HARMONY-3454:
------------------------------------------
Alexey A. Ivanov suggests in HARMONY-3453:
I think it's better to use HashMap/HashTable for storing registered EditorKits because of performance reasons.
On the other hand I guess there won't be many items registered, thus making performance gains very low.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Beyer resolved HARMONY-3454.
-----------------------------------
Resolution: Fixed
The patches have been applied. Please verify. Thanks.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Assigned To: Nathan Beyer
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Alexey A. Ivanov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486015 ]
Alexey A. Ivanov commented on HARMONY-3454:
-------------------------------------------
You can leave the localization as is but localize "Content type" string using the same localization way: I mean
throw new NullPointerException(Messages.getString("swing.03", Messages.getString("swing.xx"));
where Messages.getString("swing.xx") returns "Content type".
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486000 ]
Vasily Zakharov commented on HARMONY-3454:
------------------------------------------
Sure, I'm working on the test.
I didn't want to touch localization. I only used the same messages that already existed. However you're probably right, and I'll add necessary messages.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486094 ]
Vasily Zakharov commented on HARMONY-3454:
------------------------------------------
Alexey, I'm not sure that localizing strings like "Content type" is a good idea, as they reference the API documentation, and localizing them would make it harder to find out the cause for the error.
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-fix.patch, Harmony-3454-make.patch, Harmony-3454-test.patch, Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-3454) [classlib][swing]
JEditorPane.createEditorKitForContentType() uses wrong classloader
Posted by "Vasily Zakharov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasily Zakharov updated HARMONY-3454:
-------------------------------------
Attachment: Test.java
> [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
> ------------------------------------------------------------------------------------
>
> Key: HARMONY-3454
> URL: https://issues.apache.org/jira/browse/HARMONY-3454
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Reporter: Vasily Zakharov
> Priority: Minor
> Attachments: Test.java
>
>
> Consider the attached test.
> It creates a thread, sets a context classloader for it, and than calls registerEditorKitForContentType() with no classloader specified (1), null classloader (2) and another specific classloader (3). Then in the same thread it calls createEditorKitForContentType for all three registered content types (results 1, 2, 3). Next, it creates another thread, with default context classloader, in which again calls createEditorKitForContentType again for all three registered types (results 4, 5, 6).
> Note: try-catch block in ThreadCheckEditorKit.run() and NPE stack in the RI output are due to what I consider a bug in RI implementation (see HARMONY-3453), and do not affect this issue effectively.
> Output on RI:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Unknown Source)
> at javax.swing.JEditorPane.registerEditorKitForContentType(Unknown Source)
> at Test$1ThreadCheckEditorKit.run(Test.java:33)
> 1: MyEditorKit@190d11 : ArrayClassLoader@19821f
> 2: MyEditorKit@a90653 : ArrayClassLoader@19821f
> 3: MyEditorKit@de6ced : ArrayClassLoader@42e816
> 4: MyEditorKit@c17164 : ArrayClassLoader@19821f
> 5: MyEditorKit@1fb8ee3 : ArrayClassLoader@19821f
> 6: MyEditorKit@61de33 : ArrayClassLoader@42e816
> Output on Harmony:
> 1: null
> 2: null
> 3: MyEditorKit@5ce45ce4 : ArrayClassLoader@4c784c78
> 4: null
> 5: null
> 6: MyEditorKit@78547854 : ArrayClassLoader@4c784c78
> The null values in cases 1, 2, 4, 5 are due to Harmony implementation of createEditorKitForContentType() uses Class.forName(className) to load EditorKit classes, while it should use Class.forName(className, true, Thread.currentThread().getContextClassLoader()), as RI does (as may be seen clearly from the output above). This situation is very similar to HARMONY-3398 and HARMONY-3420.
> The test doesn't set a context class loader for the second thread, however, RI manages to create EditorKit instances in cases 4 and 5 successfuly. This means that Thread.currentThread().getContextClassLoader() should be called not in createEditorKitForContentType(), but in registerEditorKitForContentType() instead, and the result should be put to the registration table.
> createEditorKitForContentType() may be left as it is, however, it's better be simplified to use Class.forName(kitName, true, loader) in all cases, which is equivalent to the current code. Also, catch statements in createEditorKitForContentType() are better be adjusted, as besides IllegalAccessException, ClassNotFoundException and InstantiationException, also LinkageError and ClassCastException may be thrown as well. It looks like catching Throwable is appropriate in this case.
> The attached patch addresses all the changes above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.