While I was working on serializing the CFC to allow replication of CFCs across sessions, I encountered a blocking issue with class loaders. Here is what it was and how I got around it.

Class loaders are hierarchically organized, where each class loader has a parent class loader, except the bootstrap class loader which loads the core java libraries. At any point in time, a class loader does not know about the classes loaded by its descendant class loaders. For more information about class loader, refer this article.

All the ColdFusion classes are loaded by a custom ColdFusion class loader. The effective class loader of the server during session replication is the one above the ColdFusion class loader in the class loader heirarchy. This class loader will not be able to find the ColdFusion classes and a ClassNotFoundException was thrown when the session containing CFCs was replicated.

The workaround here was to replace the CFC instance with a proxy object instance (whose class is visible to the effective class loader during session replication) while serializing the CFC instance. While deserializing the proxy object instance, the instance of the CFC can be recreated and the proxy object replaced.

The readResolve and writeReplace methods of the Java Serialization API provide a way to exactly achieve this.

Object readResolve()
Object writeReplace()

These methods allow an object to provide an alternative representation of itself during the serialization of the object.

Session replication of the CFC worked fine with these two methods actively being used in the background. The CFC being serialized is replaced with an alternate representation through the writeReplace method. This alternate representation is then replaced by the instance of the CFC when the alternate representation is deserialized and the readResolve method is invoked.

Comments

Leave a Reply