Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 1 Nov 2013 17:17:20 +0000 (UTC)
From: "Oliver Heger (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12676709.1383162625487.7697.1383326240781@arcas>
In-Reply-To: <JIRA.12676709.1383162625487@arcas>
References: <JIRA.12676709.1383162625487@arcas>
Subject: [jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance()
 pseudo-singleton causes problems with Java 7 parallelized class loader
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/BEANUTILS-450?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
3811467#comment-13811467 ]=20

Oliver Heger commented on BEANUTILS-450:
----------------------------------------

What I mean is that the converter registration now happens in the same thre=
ad that also accesses them. Did I understand this correctly? Are other thre=
ads involved which also do something with converters?

> BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 =
parallelized class loader
> -------------------------------------------------------------------------=
-------------------------
>
>                 Key: BEANUTILS-450
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-450
>             Project: Commons BeanUtils
>          Issue Type: Bug
>          Components: Bean / Property Utils, ConvertUtils & Converters
>    Affects Versions: 1.7.0
>         Environment: Java 7u25+, Windows 7 32-bit desktop environments
>            Reporter: Matthew Hall
>            Priority: Blocker
>
> From an email I sent to the BeanUtils users mailing list:
> We recently tracked a bug in our software that started showing up with Ja=
va 7 back to an incompatibility between BeanUtilsBean.getInstance() pseudo-=
singleton instance model, Java 7=E2=80=99s parallelized class loader, and t=
he fact that we were registering Converters with ConvertUtils inside of a s=
tatic class-level block. As far as I=E2=80=99m able to tell, this wasn=E2=
=80=99t a problem in previous versions of Java because the class loader was=
 not parallelized, meaning that the class loader that handled the registrat=
ion of our converters was the same class loader that was in use when Conver=
tUtilsBean.getInstance() was invoked. Now, with Java 7, it seems that there=
 is no guarantee that the class loader that executes the static block conta=
ining the Converter registration is the same one in use when ConvertUtilsBe=
an.getInstance() is invoked, meaning that our custom Converters are not nec=
essarily available everywhere they used to be.
> I=E2=80=99m writing to the list today to ask three things about this situ=
ation:
>  1.  First off, is this the correct explanation for the reason that it se=
ems we=E2=80=99re not guaranteed to have our custom Converters loaded in Ja=
va 7.
>  2.  In order to ensure that a different class loader thread is not in us=
e when the Converters are registered with ConvertUtils, we=E2=80=99ve moved=
 this registration from a static class-level block into a user interface se=
tup method that is executed before the Converters are used.
>  3.  Given that Java 7 introduced parallelized class loading in the base =
ClassLoader and that BeanUtilsBean builds instances on a per-classloader ba=
sis, should this issue be raised to the BeanUtils developers?
> Below you=E2=80=99ll find some pseudocode that illustrates our situation:
> {code}
> public class UtilitiesClass {
>    ...
>    static {
>        registerConverters();
>    }
>    public static void registerConverters() {
>        ConvertUtils.register(new OurCustomColorConverter(), java.awt.Colo=
r.class);
>    }
>    ...
> }
> public class MainGUIClass {
>    ...
>    public static void main(String[] args) {
>        MainGUIClass mainGui =3D new MainGUIClass();
>        mainGui.setup();
>        mainGui.show();
>    }
>    public void setup() {
>        UIManager.setLookAndFeel(new LookAndFeelClass());
>    }
>    public void show() {
>        ((OurLookAndFeelClass) UIManager.getLookAndFeel()).getColor();
>    }
>    ...
> }
> public class LookAndFeelClass extends LookAndFeel {
>    ...
>    public java.awt.Color getColor(String colorString) {
>        return (java.awt.Color) ConvertUtils.convert("someValidColorString=
", java.awt.Color.class);
>    }
>    ...
> }
> {code}
> In the above example, the cast of the results of ConvertUtils.convert to =
Color in LookAndFeelClass.getColor(String) sometimes results in a runtime e=
xception with the message =E2=80=9Cjava.lang.String cannot be cast to java.=
awt.Color.=E2=80=9D. This appears to be due to the fact that ConvertUtils.c=
onvert() fails over to the built-in String.class Converter if it cannot fin=
d a Converter for the specified class. In production environments, it was c=
ompletely unpredictable as to when this would happen and what would make th=
e problem go away.
> The fix we implemented was to move the registration of OurCustomColorConv=
erter() from the static block inside of UtilitiesClass to the first line of=
 MainGUIClass.setup(), before the LookAndFeel is loaded. Will this fix be s=
ufficient, or does it still suffer from the thread issue, if that is indeed=
 the root cause of the problem?


--
This message was sent by Atlassian JIRA
(v6.1#6144)