[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817661#comment-13817661
]
Matthew Hall commented on BEANUTILS-450:
Thanks, Oliver. We suspected that the console was affecting the behavior in a
manner similar to your assessment. I'll be looking into your proposal to move
ConvertUtils access in our application to within a static block in the same
class that the converter registrations occur. I will let you let you know the
results. Thanks again!
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812875#comment-13812875
]
Matthew Hall commented on BEANUTILS-450:
We ensure this in our use by registering the converters before creating the
LookAndFeel object that uses them. They are registered earlier in the same
method that creates and installs the LookAndFeel for our application. This
guarantees that, from an application flow standpoint, the converters would be
registered before any attempted use, just as registering them within a static
block would.
I think it's important to note that the exact same behavior is exhibited with
the reworked version as with the version that registered the converters in a
static block. All Java 6 clients have no problems whatsoever. Some Java 7
clients report the issue, but when it is reported the workaround of enabling
the Java console is reliable.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812066#comment-13812066
]
Oliver Heger commented on BEANUTILS-450:
I see. How do you ensure that the converter registration actually happens
before their use? In the first approach using a static block in an utility
class, was the utility class accessed by all threads before converters were
used? How is this solved in the revised version?
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811183#comment-13811183
]
Benedikt Ritter commented on BEANUTILS-450:
---
{quote}
I think, we can assume that basic converter registration works in BeanUtils;
otherwise we would have received numerous bug reports.
{quote}
Maybe this is specifically related to BU in a Java 7 environment?
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811273#comment-13811273
]
Matthew Hall commented on BEANUTILS-450:
I think it is related to using BU in a Java 7 environment. Oliver, our original
implementation registered our custom converter in a static block, before any
application code was executed. Yet, when the application code went to use
ConvertUtils, the converter does not appear to be registered. In this original
implementation, our application threads have nothing to do with the behavior;
registering the converters in a static block guarantees that they are
registered before any application code that uses them is executed. This was
always successful under Java 6, but under Java 7 the converters don't seem to
always be registered to all application classes. I'm asserting that this is due
to the combination of BeanUtilsBean's pseudo-singleton class loader thread
instance generation paradigm in combination with the new multi-threaded class
loader in Java 7.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
and what would make the problem go away.
The fix we implemented was to move the
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811393#comment-13811393
]
Oliver Heger commented on BEANUTILS-450:
This may all be true. But you said the problem still persists even if you
removed the initialization in the static block and pushed it directly before
the code which uses the converters. I try to find an explanation for this
effect.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811397#comment-13811397
]
Matthew Hall commented on BEANUTILS-450:
We didn't move it immediately before the code which uses the converters. We
moved it from the static block into one of our GUI initialization methods
before any other GUI setup work is done. If you'll take a look at the first
comment I left here, you'll see that the call to register the converters is now
in MainGUIClass.setup() while LookAndFeelClass.getColor() is still where it is
attempted to be used from.
Unfortunately, this is the only change that I'm going to be able to give a
definitive example of. After we made this change and were still seeing the
problem, it was decided that no more changes would be made unless we can be
sure that we totally understand the issue (as we have other parts of our system
that use ConvertUtils as well).
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811467#comment-13811467
]
Oliver Heger commented on BEANUTILS-450:
What I mean is that the converter registration now happens in the same thread
that also accesses them. Did I understand this correctly? Are other threads
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811563#comment-13811563
]
Matthew Hall commented on BEANUTILS-450:
Our application is multi-threaded and has work being done on different threads
that do use ConvertUtils. Prior to upgrading to Java 7, all of these threads
had visibility to the same converters that were registered with ConvertUtils.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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 happen
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 issue,
if that is indeed the root cause of the problem?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13810684#comment-13810684
]
Oliver Heger commented on BEANUTILS-450:
This is indeed strange.
IIUC, you effectively eleminated all concurrency related possibilities. You do
the converter registration directly - and in the same thread - before you call
an operation which uses the converters, right? Nevertheless the issue shows the
typical symptoms of a concurrency bug.
I think, we can assume that basic converter registration works in BeanUtils;
otherwise we would have received numerous bug reports. So I see the following
options:
* The exception you get is not thrown by the operation you think, but by some
other code running in parallel and *before* you do the registration. Can you
check this with the exception stack trace?
* In the time between the converter registration and the usage of the
converters another thread manipulates the converters. Could it be that there
are multiple places in which converters are registered?
I do not have a clear understanding about which threads are running in your
application. So it is hard to figure out what is actually going on.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
exception with the message “java.lang.String cannot be cast to
java.awt.Color.”. 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
[jira] [Commented] (BEANUTILS-450) BeanUtilsBean.getInstance() pseudo-singleton causes problems with Java 7 parallelized class loader
[
https://issues.apache.org/jira/browse/BEANUTILS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809538#comment-13809538
]
Matthew Hall commented on BEANUTILS-450:
We originally suspected this issue to be caused by the fact that we were
calling our converter registration method from within a static block, so we
moved the registration into the MainGUIClass setup function, like so:
{code}
public class UtilitiesClass {
...
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = new MainGUIClass();
mainGui.setup();
mainGui.show();
}
public void setup() {
UtilitiesClass.registerConverters();
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}
This change has not solved the issue. I've marked this ticket as a blocker
because we do have applications in production that cannot launch due to this
problem, when it appears. We're also concerned that other converters we use in
our system for date and time format conversions are potentially impacted by
this issue as well. We currently haven't made any changes to how those are
registered, though.
One other thing that might be important to note is that we've discovered that
enabling the Java console seems to mitigate the issue.
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 Java 7
back to an incompatibility between BeanUtilsBean.getInstance()
pseudo-singleton instance model, Java 7’s parallelized class loader, and the
fact that we were registering Converters with ConvertUtils inside of a static
class-level block. As far as I’m able to tell, this wasn’t a problem in
previous versions of Java because the class loader was not parallelized,
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 that there is no guarantee that the
class loader that executes the static block 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’m 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’re 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’ve moved this
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’ll find some pseudocode that illustrates our situation:
{code}
public class UtilitiesClass {
...
static {
registerConverters();
}
public static void registerConverters() {
ConvertUtils.register(new OurCustomColorConverter(),
java.awt.Color.class);
}
...
}
public class MainGUIClass {
...
public static void main(String[] args) {
MainGUIClass mainGui = 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
