Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <30866741.1175539232960.JavaMail.jira@brutus>
Date: Mon, 2 Apr 2007 11:40:32 -0700 (PDT)
From: "Vasily Zakharov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-3454) [classlib][swing]
 JEditorPane.createEditorKitForContentType() uses wrong classloader
In-Reply-To: <11317050.1174444652416.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.