ColdFusion 9's ObjectSave() And ObjectLoad() Life Cycle Removes Object Meta Data
The other day, when experimenting with ColdFusion 9's ObjectSave() and ObjectLoad() functions, I found that I was having trouble using some of the deserialized object's meta data. I could invoke both the defined and synthesized functions. I could even check to see if a given method existed; but, it seemed to be impossible to ask a deserialized component for any kind of meta data.
To demonstrate this, I've created this very simple ColdFusion component. You'll notice that it has both explicitly defined methods as well as synthesized accessor methods:
Woman.cfc
<cfcomponent
output="false"
accessors="true"
hint="I provide lady behavior.">
<!--- Define properties that get accesssors. --->
<cfproperty name="name" type="string" />
<cfproperty name="age" type="numeric" />
<cfproperty name="hair" type="string" />
<cffunction
name="init"
access="public"
returntype="any"
output="false"
hint="I return an initialized object.">
<!---
Return this object reference for method chaining.
Remember, in ColdFusion 9, the NEW operator requires
the use of a return value.
--->
<cfreturn this />
</cffunction>
<cffunction
name="getMood"
access="public"
returntype="numeric"
output="false"
hint="I return the mood. Mostly, I just wanted another manually created function here outside of init() for testing.">
<!--- Return a random mood. --->
<cfreturn randRange( 4, 10 ) />
</cffunction>
</cfcomponent>
Now, I'm going to take that ColdFusion component (CFC), instantiate it, populate it, and then output its meta data. Then, I'm going to bring it through ColdFusion's new binary serialization life cycle using ObjectSave() and ObjectLoad() before I try to, once again, output the meta data:
<!--- Create a new woman and set some properties. --->
<cfset sarah = new Woman() />
<cfset sarah.setName( "Sarah" ) />
<cfset sarah.setHair( "Brown" ) />
<cfset sarah.setAge( 33 ) />
<!--- Output the component data. --->
<cfoutput>
<h2>
Before Serialization
</h2>
<p>
Function Count:
#arrayLen( getMetaData( sarah ).functions )#
</p>
<p>
Keys: #structKeyList( sarah )#
</p>
<p>
Collection:
<cfloop
item="key"
collection="#sarah#">
#key#,
</cfloop>
</p>
<p>
Name Exists: #structKeyExists( sarah, "getName" )#<br />
</p>
<p>
Name: #sarah.getName()#<br />
Hair: #sarah.getHair()#<br />
Age: #sarah.getAge()#<br />
</p>
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<!--- Serialize and deserialize. --->
<cfset woman = objectLoad( objectSave( sarah ) ) />
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<!--- ------------------------------------------------- --->
<h2>
After Serialization
</h2>
<p>
Function Count:
<cftry>
#arrayLen( getMetaData( woman ).functions )#
<cfcatch>
GetMetaData() Failed!
</cfcatch>
</cftry>
</p>
<p>
Keys: #structKeyList( woman )#
</p>
<p>
Collection:
<cfloop
item="key"
collection="#woman#">
#key#,
</cfloop>
</p>
<p>
Name Exists: #structKeyExists( woman, "getName" )#<br />
</p>
<p>
Name: #woman.getName()#<br />
Hair: #woman.getHair()#<br />
Age: #woman.getAge()#<br />
</p>
</cfoutput>
When I run this code, I get the following output:
Before Serialization
Function Count: 8
Keys: getMood,init
Collection: getMood, init,
Name Exists: YES
Name: Sarah
Hair: Brown
Age: 33After Serialization
Function Count: GetMetaData() Failed!
Keys:
Collection:
Name Exists: YES
Name: Sarah
Hair: Brown
Age: 33
As you can see, I was able to invoke all of the component methods both before and after serialization. I was even able to check to see if a given method - getName - existed in the given component. Beyond that, however, once a ColdFusion component has been serialized and deserialized, I was not able to query it for any kind of meta data. Calls to getMetaData() throw an error; the key list is empty; and, trying to treat the deserialized component as a collection yields absolutely no results.
I believe that all of this behavior hinges on the way that ColdFusion stores component meta data. As we've seen before, component meta data is much stickier in ColdFusion 9 than it has been in previous versions. The collection behavior probably depends on the key list behavior which probably depends on the cached meta data of the object. As such, losing the meta data results in losing a good amount of reflective functionality.
Want to use code from this post? Check out the license.
Reader Comments
Nice catch Ben, I'm using this in a few places for a new project I've been working on, and hadn't yet noticed that behavior. Definitely a bug I'm going to have to watch out for...
Dan
@Daniel,
The objectSave() stuff is definitely very cool, but a bit funky. What kind of stuff are you using it for, if I may ask.
@Ben,
It'll mostly be used for persistance across application and server restarts. Complex objects that I'd rather not rebuild after an application or server restart will be saved out onApplicationEnd and then reconstituted (I just wanted to use that word) when the application starts back up.
Dan
@Daniel,
Sounds cool. I think the persistence of complex objects across application bootups is probably one of the coolest things about object serialization. At least, for someone like me in a single-server world.
Good word ;)
I'm also seeing issues where ObjectSave() throws errors when you try to serialize an object that uses onMissingMethod. Just FYI.
@Doug,
Hmmm, that's a really weird error?? I wonder what on earth would cause that.
Well, I must confess to jumping to conclusions. It would seem that onMissingMethod isn't a problem at all. The only reason I said this was is because the Java stack trace that was output when I tried to use ObjectSave() mentioned onMissingMethod that near the top.
Upon further research I've determined that ObjectSave() fails when you try to serialize an object that is composed of non serializable Java objects. IE, you've loaded a non-serializable class into the variables scope of a CFC. With a weekend's worth of recharge time this is now a rather obvious.
Whoops!
I've been playing with these functions as well and noted that the loadObject() function will fail with a "Null pointer exception" error if the original CFC file no longer exists or has been moved or renamed. If you add properties or methods to the CFC, they will mysteriously appear in the deserialized object that was serialized before those properties/methods had been added or removed. I can't seem to find any definitive documentation on this, but my theory is that the saveObject() function is taking the values of any properties that have been set and saving the property names and the current non-default values, as well as a reference to the original CFC file, and serializing that data only.
When loadObject() is called, it reads that pointer/reference back to the original CFC file, instantiates a new instance, then sets the properties with their non-default values that were saved with the serialized copy. I'm not sure how that ties in with the loss of meta data.
In any case, be careful how you use this serialization. If that original CFC file gets moved or renamed then the data can no longer be deserialized, even if the CFC is now in the same folder or a mapping available to the template doing the deserialization. I haven't tried this between servers yet (i.e. putting a copy of the CFC file at the same path location on a different server and trying to deserialize). From other's comments it would appear to work fine across server restarts though.
My curiosity got the better of me and I tried to deserialize a CFC on a different server which has no knowledge of the original CFC file. The initial deserialization attempt fails with the "null pointer" error as expected. However, when the CFC is placed at the same file path as the CFC on the original server where the data was serialized, it also throws the "null pointer" error. If the CFC is placed in the same folder as the code calling the deserialization it will work properly. So, apparently the deserialization will work across servers as long as a copy of the CFC is present on the deserializing server. Perhaps the original CFC file can be moved as long as the ColdFusion server is restarted. Perhaps the reference in the serialized data is just to the name of the CFC (and perhaps part of its signature; I got funky results if the "accessors" attribute was changed from true to false before deserializing) and ColdFusion looks to its cache to see if a copy of that CFC has been instantiated since the last server reload and looks for the file at that location and gives up if it isn't there any longer, but upon server restart it wouldn't have that cached and would start looking in the current folder and mappings to get a fresh copy to instantiate. Interesting stuff in any case.
@Justin,
Ha ha, I love your cross-server experiment! Awesome find. Yeah, the concept of Object serialization kind of boggles my mind a bit, but your explanation sounds accurage. I can mentally model the concept of JSON or XML since you are simply creating a "representation" of an object; but, since this uses binary data as the intermediary, it creates a mental barrier for me a bit.
Anyway, great digging!