You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nd...@apache.org> on 2007/04/12 00:59:31 UTC
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.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.
>
>
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.
>
>