harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [jira] Commented: (HARMONY-3454) [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
Date Thu, 12 Apr 2007 06:15:20 GMT
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

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>

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.


Related links:

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
>I experience three stable failures of JEditorPane tests on my Windows
>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
>Unexpected exception :www.apache.org/ - Socket is not
>junit.framework.AssertionFailedError: Unexpected exception
>:www.apache.org/ - Socket is not connected at
>java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
>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
>at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
>java.lang.NoClassDefFoundError: javax.swing.text.html.parser.Lexer at
>52) at javax.swing.text.html.parser.Parser.parse(Parser.java:399) at
>) at
>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
>_MultithreadedTest.java:22) at
>org.apache.harmony.luni.util.NotImplementedException at
>itorPane.java:159) at
>torPane.java:99) at
>ext(JEditorPane_AccessibleJEditorPaneHTMLTest.java:50) at
>java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) at
>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
>at java.awt.EventDispatchThread.run(EventDispatchThread.java:48)
> Vasily
>-----Original Message-----
>From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
>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.
>On 4/11/07, Vasily Zakharov (JIRA) <jira@apache.org> wrote:
>>     [
>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
>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
>make patch back.
>> Thank you!
>> > [classlib][swing] JEditorPane.createEditorKitForContentType() uses
>wrong classloader
>> >
>> >
>> >                 Key: HARMONY-3454
>> >                 URL:
>> >             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-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
>the RI output are due to what I consider a bug in RI implementation
>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
>> > 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.

View raw message