From manico.james@gmail.com on November 02, 2010 01:09:00

Thank you for this Patrick. We will apply this to 1.4 before the next release.

Labels: Milestone-Release1.4

From skwee...@gmail.com on August 03, 2011 16:49:07

Is this fix in the 2.0 GA release (or later)?

From wettstei...@gmail.com on August 18, 2011 05:20:04

The singletons are implemented using a double-checking mechanism and a volatile reference variable. This approach is thread-safe for JDK 1.5 and higher, but it is not for previous versions (see http://java.dzone.com/articles/design-patterns-revisited-1-si ). Therefore I would recommend to use a static instance variable (has the additional benefit of less lines of code) or if performance is a concern to use the "initialization-on-demand-idiom" ( http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom )

From patrick....@gmail.com on August 18, 2011 06:35:48

Were you referring to the patch or to what's in the 1.4 source control repository? I haven't checked the source repo but the patch does not use volatiles. It synchronizes on a lock before doing any checking, which is what 1.4 requires to do lazy initialization without introducing a holder class.

From wettstei...@gmail.com on August 31, 2011 08:41:01

I was talking about the actual code in the trunk (see DefaultEncoder for example)

From nemi5...@gmail.com on August 07, 2012 11:48:32

We are experiencing this issue. What do you suggest since it does not look like this will be fixed any time soon?

From patrick....@gmail.com on August 07, 2012 12:38:48

nemi5150: you can apply my patch (attached to this issue).

wettstein.frank: I don't understand your comment. The patch is against the 1.4 branch, not trunk, and already uses static instance variables. Perhaps the initialization-on-demand-idiom would be best here, but it's more complex. I assume the patch was never applied because of your concerns, but I don't understand how they are relevant to the 1.4 branch.

From nemi5...@gmail.com on August 07, 2012 13:36:14

Patrick, I have looked at your patch, but it does not seem to be addressing the root cause of the problem. Isn't the root cause that a constructor is initializing a static variable? This is straight from do-not-do 101. I do not understand why this static variable is not initialized in a static block? That way it will only ever be initialized once and only when the class is loaded the first time by the classloader.

From nemi5...@gmail.com on August 07, 2012 13:40:02

Wait, I see. Maybe you should reopen issue 143 ? It may be fixed in a later build, but 1.4.4 is the latest stable, correct? If so, then 1.4.5 needs to be stabilized. 1.4.5 in Early Release Only since Aug-2010? Really?

From patrick....@gmail.com on August 08, 2012 12:29:06

I was using ESAPI for output encoding only, and switched to the OWASP Reform library. If you only need encoding, I would check it out: https://www.owasp.org/index.php/Category:OWASP_Encoding_Project

From kevin.w.wall@gmail.com on September 01, 2014 17:35:13

This issue is already fixed in ESAPI 2.x and ESAPI 1.4.x is no longer supported. Even if this issue were to be fixed in ESAPI 1.4.x, it would still leave many other bugs--some of which are security issues--as unfixed. Therefore, this bug nor any others that are specific to ESAPI 1.4.x, will be fixed.

Status: WontFix
Owner: kevin.w.wall@gmail.com