harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zakharov, Vasily M" <vasily.m.zakha...@intel.com>
Subject RE: [jira] Commented: (HARMONY-3454) [classlib][swing] JEditorPane.createEditorKitForContentType() uses wrong classloader
Date Wed, 11 Apr 2007 23:38:42 GMT
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) <jira@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.
>
>

Mime
View raw message