Revision 1226228

"Applied fix from trunk for revision: 1226223"  (tree conflict handled by hand: no UtilIO.java)
------------------------------------------------------------------------
r1226223 | jleroux | 2012-01-01 10:57:50 +0100 (dim., 01 janv. 2012) | 9 lines

A patch from Martin Kreidenweis "Deserialization of arrays with UtilObject.getObject() throws ClassNotFoundException" https://issues.apache.org/jira/browse/OFBIZ-4295

Deserialization of arrays with UtilObject.getObject() throws a ClassNotFoundException. This happened to us when we enabled the distributed cache clear feature and it was sending arrays of EntityExpr objects to other OFBiz instances.

The reason is, that the org.ofbiz.base.util.ObjectInputStream calls classLoader.loadClass(name) directly instead of using Class.forName(name, init, classLoader).
According to java bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627 ClassLoader.loadClass() is not intended to being used this way and doesn't support loading arrays.

jleroux: Sun/Oracle is pretty clear about that <<[When you want to reflectively load a class by name initiated using a specific class loader, you should not invoke that loader's public loadClass method directly-- instead, you should always use the static three-argument Class.forName method.  The ClassLoader.loadClass instance method is more intended for delegation from one class loader to another within a class loading operation (although this is a common confusion and not well described in the documentation).  In other words, replace L.loadClass(N) with Class.forName(N,false,L).  The Class.forName invocation may eventually end up invoking loadClass on the specified loader, but only after taking care of some other aspects of the VM's standard symbolic class name resolution process-- the significant bit in this case being the support for loading/creation of array classes.]>> More at the link above

------------------------------------------------------------------------