Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <C2FBD4D2-0873-4F99-8E01-38FA6B193441@intervolve.com>
References: <C2FBD4D2-0873-4F99-8E01-38FA6B193441@intervolve.com>
Date: Fri, 25 Oct 2013 10:12:06 +0200
Message-ID: 
 <CAB917R+7Osx4jD8vLRmXivCY9MmvJk4rPkEajh1hzOmX97=XNg@mail.gmail.com>
Subject: Re: [beanutils] BeanUtilsBean.getInstance() pseudo-singleton
 implications in a Java 7 parallel class loading environment
From: Benedikt Ritter <britter@apache.org>
To: Commons Users List <user@commons.apache.org>
Content-Type: multipart/alternative; boundary=047d7b624d3460001804e98c4e76

--047d7b624d3460001804e98c4e76
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello Matt,

about the mailing lists: the separation is a bit fuzzy :-) The user list
usually is concerned about problems and question around using components
while we discuss the development of the components on the dev list. What
you have described is on the one hand a problem while using beanutils. On
the other hand it indicates a decent problem in the overall architecture of
BeanUtils (which we would normally discuss on the dev ML).

Now back to your problem: To be honest I can not comment about this at all,
since I don't have the required test environment. But since I know
BeanUtils is implemented, I think it is possible that your assumptions are
correct.
You should definitely file an Issue in JIRA [1] that describes the problem.
If you're able to create a test that reproduces it, this would be awesome.

That said: BeanUtils is a very old component and we have already started
work on a refurbished version of it, that doesn't have the problems
BeanUtils has [2]. The problem you're describing is deeply rooted in the
architecture of BeanUtils, so I don't expect it to be fixed in a binary
compatible release.
Sadly I don't have the time to push BeanUtils2 out atm, but I expect it to
be released in early 2014 maybe, if I find some time to work on it again
(any help is welcome here ;-)

HTH at least a little bit. Feel free to join the dev ML and bring this
discussion up again, there.
Welcome to commons!

Benedikt

[1] https://issues.apache.org/jira/browse/BEANUTILS
[2] http://commons.apache.org/sandbox/commons-beanutils2/


2013/10/24 Matthew Hall <mhall@intervolve.com>

> Hello everyone,
>
> First off, I=92m not sure that the user list is the right place for this,
> but I figured I=92d try before sending it right to the dev list.
>
> We recently tracked a bug in our software that started showing up with
> Java 7 back to an incompatibility between BeanUtilsBean.getInstance()
> pseudo-singleton instance model, Java 7=92s parallelized class loader, an=
d
> the fact that we were registering Converters with ConvertUtils inside of =
a
> static class-level block. As far as I=92m able to tell, this wasn=92t a p=
roblem
> in previous versions of Java because the class loader was not parallelize=
d,
> meaning that the class loader that handled the registration of our
> converters was the same class loader that was in use when
> ConvertUtilsBean.getInstance() was invoked. Now, with Java 7, it seems th=
at
> there is no guarantee that the class loader that executes the static bloc=
k
> containing the Converter registration is the same one in use when
> ConvertUtilsBean.getInstance() is invoked, meaning that our custom
> Converters are not necessarily available everywhere they used to be.
>
> I=92m writing to the list today to ask three things about this situation:
>
>   1.  First off, is this the correct explanation for the reason that it
> seems we=92re not guaranteed to have our custom Converters loaded in Java=
 7.
>   2.  In order to ensure that a different class loader thread is not in
> use when the Converters are registered with ConvertUtils, we=92ve moved t=
his
> registration from a static class-level block into a user interface setup
> 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
> basis, should this issue be raised to the BeanUtils developers?
>
> Below you=92ll find some pseudocode that illustrates our situation:
>
> public class UtilitiesClass {
>     ...
>     static {
>         ConvertUtils.register(new OurCustomColorConverter(),
> java.awt.Color.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);
>     }
>     ...
> }
>
> In the above example, the cast of the results of ConvertUtils.convert to
> Color in LookAndFeelClass.getColor(String) sometimes results in a runtime
> exception with the message =93java.lang.String cannot be cast to
> java.awt.Color.=94. This appears to be due to the fact that
> ConvertUtils.convert() fails over to the built-in String.class Converter =
if
> it cannot find a Converter for the specified class. In production
> environments, it was completely unpredictable as to when this would happe=
n
> and what would make the problem go away.
>
> The fix we implemented was to move the registration of
> OurCustomColorConverter() from the static block inside of UtilitiesClass =
to
> the first line of MainGUIClass.setup(), before the LookAndFeel is loaded.
> Will this fix be sufficient, or does it still suffer from the thread issu=
e,
> if that is indeed the root cause of the problem?
>
> --Matt
>
> Matthew Hall
> Enterprise Application Developer || | Intervolve, Inc.<
> http://www.intervolve.com/>
> mhall@intervolve.com<mailto:mhall@intervolve.com> | +1-919-865-4400 ext.
> 701
>
>


--=20
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

--047d7b624d3460001804e98c4e76--