After reading this article http://www.javaworld.com/jw-02-2001/jw-0209-double.html about the double-checked locking idiom I looked at resolveClass() in DefaultClassResolver. Comparing the example in the article and the resolveClass() method I got the impression that resolveClass() might not work as expected:
The local variable clz might be not null since another thread working in the synchronized block has just created the reference. Yet, the object behind clz might not be fully constructed. The test clz == null will fail returning a not fully initialized object.
Synchronizing the whole method should fix the problem.
Dirk
- [Wicket-develop] resolveClass in DefaultClassResolver Dirk Markert
- Re: [Wicket-develop] resolveClass in DefaultClassResolv... Igor Vaynberg
- Re: [Wicket-develop] resolveClass in DefaultClassRe... Dirk Markert
- Re: [Wicket-develop] resolveClass in DefaultCla... Igor Vaynberg
- Re: [Wicket-develop] resolveClass in Defaul... Igor Vaynberg
- Re: [Wicket-develop] resolveClass in Defaul... Dirk Markert
- Re: [Wicket-develop] resolveClass in D... Igor Vaynberg
