Skip to main content
Ben Nadel at the New York ColdFusion User Group (May. 2009) with: Gert Franz
Ben Nadel at the New York ColdFusion User Group (May. 2009) with: Gert Franz ( @gert_railo )

GetMetaData() Is Shared By All Instances Of A Given Class In ColdFusion

Published in Comments (10)

This is just a minor note, but I found out the other day that the structure returned from ColdFusion's GetMetaData() method is not unique to the instance on which it was called. Rather, the structure seems to be shared among all instances of a given class (component definition). This means that if you update the Meta Data for a given CFC instance, it updates the Meta Data for all instances of the same time. And what's more, this has nothing to do with the persistence of any of the objects in question. Even if you do this on a page where the object is not cached, newly created instances of the given component on subsequent page requests will still have the updated meta data. And, on top of that, the Meta Data does not seem to be related to the application timeout. I guess the meta data for a given class gets stored in the trusted cache or something?

To see this in action, take a look at the following code:

<!--- Create a test component. --->
<cfset firstTest = createObject( "component", "Test" ) />

<!--- Create another test component. --->
<cfset secondTest = createObject( "component", "Test" ) />

	Now that we have two instances of our test component,
	update the meta data for just one of them.
<cfset getMetaData( firstTest ).forBlog = true />

	Output the meta data for both components to see how
	they were updated.
	var="#getMetaData( firstTest )#"
	label="First Test Object"

<br />

	var="#getMetaData( secondTest )#"
	label="Second Test Object"

The actual component here is empty, which is irrelevant. What's important to notice is that I am creating two separate instances of the component, but only changing the meta data on one of those instances. When they are then both CFDump'd out to the page, we get the following output:

GetMetaData() Structure Is Shared Among All Instances Of A Given Class In ColdFusion.

As you can see, the meta data for both of the ColdFusion component instances now contains the "forBlog" key even though only one of the instance' meta data was directly updated.

This is a really minor piece of information; but, I recently started playing around with meta data and this minor point became an important caveat to understand. Perhaps more on this later.

Want to use code from this post? Check out the license.

Reader Comments


yes yes yes!
I came across this exact same thing when working with my CFproperty Inspector code ( when working with sniffing for component properties.

This gave me some bad ideas about implementing (via coldspring) on-demand property manipulation at run time - which would essentially introspect the component, automatically update the properties of the component dynamically (based on your getter methods), and then once setup, be available to flex for Class binding etc.

I opted for writing these properties directly to the component instead, as cfproperty tags and updating them easily via Bolt's Extensions with a simple right click 'Inspect CFC' instead. (bolt extension also found on riaforge) This way you'd have more granular control over those properties that were 'meta data' in the component - but comes with some 'upkeep' in keeping this data aligned with your methods every time you add new getters.

Fun stuff -



I wouldn't say that I discovered the singleton pattern; what I did was find out that meta data for a given class is a singleton, probably creating at first compile of the code, and then shared by all instances of the class. I also figured out that it was:

A) Not created via reflection for each instance.

B) Persistent.

Although, that makes me wonder - would changing the structure of the CFC at run time change it's meta data. You've given me some more stuff to experiment with!


Yeah, writing directly to the CFC would probably be the best move. Oddly enough, I actually stumbled upon this with meta data about Function objects, not components, where there is no option to write directly.


Interesting... It seems the meta data is being stored with the template proxy cache. I guess they figured it wouldn't change much and people wouldn't try to modify it...

The cache hangs around until you run:

createObject('component','CFIDE.AdminAPI.runtime' ).clearTrustedCache('/full/path/to/your.cfc');

Or click the Clear Template Cache Now button on the Caching page in your cf admin.



Clearing the trusted cache would be interesting. I am not 100% sure of all the things that go in the trusted cache. Are these basically the compiled templates and CFCs?


Sry for the late reply. Yes, pretty much. "Template Cache" is the place in memory where compiled CFM and CFC templates are stored. When the "Trusted Cache" box is checked, in the Admin, CF doesn't inspect these requested templates for updates.

This is server-wide tho (w/ a "Clear Template Cache Now" button in the Admin). I'd like to leave Trusted Cache enabled, but have ability to "reset" a specific app's portion of this cache after uploading an updated .cfm or .cfc.

I also found one of Ahwin's blog posts pretty informative:


I must clarify that the Admin API does provide ability to clear individual templates from the cache.. What I meant, was that I want to be able to just update and upload any number of templates (such as via FTP), and then simply call the clearAppTrustedCache() function.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel