How to fix "getMetaData method was not found" error

[EugenePipko]

Hello,

I installed CF2018 on Win2016 server and moved my code into it from CF9. Now I am receiving errors that I did not receive in CF9.

09:15:16.016 - Object Exception - in D:/Application.cfc : line 249

The getMetaData method was not found.

09:15:16.016 - Application Exception - in D:/Application.cfc : line 249

An exception occurred while calling the function getMetaData.

The line 249 refers to the <cfdump> tag in the following function in Application.cfm

<cffunction name="onError" returnType="void" output="false">

<cfargument name="exception" required="true">

<cfargument name="eventname" type="string" required="true">

        <cfset var errortext = "">

        <cfif isDefined("arguments.exception.rootCause") AND arguments.exception.rootCause IS "coldfusion.runtime.AbortException">

            <cfreturn/>

        </cfif>

<cfmail

to="me@company.com"

from="cf_server@company.com"

subject="ColdFusion request failed for #UCase(listlast(SESSION.curr_user,"\"))#"

type="html">

<p><strong>Error: <font color="red">#arguments.exception.message#</font></strong></p>   

        <strong>Time:</strong> #dateFormat(now(), "short")# #timeFormat(now(), "short")#<br>

        <strong>Error on page:</strong> http://#cgi.server_name##cgi.script_name#?#cgi.query_string#<br>

        <strong>Referrer:</strong> #cgi.HTTP_REFERER#   

    <p></p>

       <cfdump var="#arguments.exception#" label="Error">

</cfmail>

    <cfabort>

</cffunction>

Does anyone know how to fix it?

Thanks,

Eugene

[Charlie Arehart]

And I will add, dmerril, that I also don't get any error running these in either CF2016 update 17 (from last month) or update 16. Your first post today said you had the problem on 2016 as well. Again, since I don't, then let's see if you may show that you are doing something different in "dumping an exception" than I show.

Or more simply, if my offered code fails for you on CF2016, then again whatever is amiss for you in 2018 (even if some CF admin config change we're not thinking of, perhaps) is also amiss in 2016. And it could be that some config setting in 2016 was imported by you into 2018. That's just a guess, though. I really can't think of an admin change that could lead that code I offered to fail. Let's see what you find. I just wanted to clarify I don't see it in 2016 either, if that's helpful.

[dmerrill]

Thanks to all who've chimed in.
Sorry to ghost on this, I was pulled away, then gone for the weekend.

First off, my initial post was in error.

I'm upgrading an app from CF9 to 2018; CF2016 was never involved.

Second, my test case was pretty much exactly yours Charlie, cftry, assign a var the value of a non-existant var, cfdump the cfcatch variable in the catch. The cfdmp  is that shows the error "The getMetaData method was not found". That's in a standalone cfm file, not something inside or expliciatly called by Application.cfc.

Third, following the unsuccessful uninstall, any cfm file throws a 500 that doesn't explain itself at all. In hf-updates I see these jars and their corresponding properties files and directories:

hotfix-010-320417.jar

hotfix-011-326016.jar

However, I also see a directory hf-2018-00008-318307, with no corresponding jar or properties file.

I'm quite sure hf08 was installed, as I recall, there were additional steps involved for that one.

That may not matter, if it's included in a later one.

In lib/updates, I see these two jars, and nothing for hf08:

chf20180010.jar

chf20180011.jar

And fourth, after following Dave Watts' instructions for deleting the hotfix manually, the server throws a 500 on any cfm, incluldeing CF Admin, and a super basic .cfm file with no cfml in it.

In server.log, I see this; some details removed for readabbility:

Installed JSafe JCE provider: Version 6.21 Crypto-J 6.2.1, EMC Corporation. JsafeJCE Security Provider ...
"Information","main","04/20/21","14:24:37","","Starting security..."
"Error","main","04/20/21","14:24:37","","Unable to initialise Security service: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception."
"Information","main","04/20/21","14:24:37","","Unable to initialise CFStartupServlet:java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception."

Any thoughts?

And thanks again for any ideas.

[dmerrill]

Any further comments folks?

At this point I'm looking at restoring that VM from backup, from before things went South completely. It's a bit of a shame, since some useful work has been done there since then, but it's very hosed at a low level now.

I have another 2018 server that hasn't been udated yet past Update 2, and it doesn't have the getMetadata() problem. Continuing with later updates may show me something too.

Thanks for any ideas.

[BKBK]

...my test case was pretty much exactly yours Charlie, cftry, assign a var the value of a non-existant var, cfdump the cfcatch variable in the catch. The cfdmp  is that shows the error "The getMetaData method was not found". That's in a standalone cfm file, not something inside or expliciatly called by Application.cfc.

By @dmerrill

For the benefit of the rest of the forum, could you please share the code in full?

[dmerrill]

Thanks for chiming in, I appreciate it.

This is my bare-bones test:

<cftry>
	<cfset asdf=qwer><!--- throw error --->
	<cfcatch>
		<cfoutput><p>ERROR: #cfcatch.message# #cfcatch.detail#</p></cfoutput>
		<cfdump var="#cfcatch#" label="" metainfo="0">
	</cfcatch>
</cftry>

The cfdump of the cfcatch var shows an error, "The getMetaData method was not found".

Note that my code doesn't call getMetadata().

Note also that it doesn't involve Application.cfc; that code is from a simple cfm file containing only that code.

However, at this point I have a worse problem, in that my attempts to install HF10 and then 11 have hosed the server completely, as indicated in my previous messages. My guess is that I'm looking at restoring that VM from the most recent snapshot of it, but if anyone has any less blunt-instrument ideas, that'd be great.

[BKBK]

@dmerrill , thanks for reopening this. I have reported the "GetMetadata method was not found" issue as a bug.

[dmerrill]

Devil's in the details 😉

@BKBKdo I gather that you're able to repoduce this? Which exact CF version?

I have two 2018 servers. The one where I saw the problem was at update 10 originally, which as I understand it others said was the version where that bug was fixed. As descibed above, since it wasn't working for me, I tried to update to Update 11 (the latest), which failed, so I tried to uninstall 10 and 11, which also failed, and my subsequent attempts to uninstall them manaually have left the server completely inoperable, 500 on anything, including CF Admin.

My other 2018 server is at update 2, and doesn't have the getMetadata() problem.

[Charlie Arehart]

Yes, BKBK, please be sure you are confirming you are experiencing this. I had already shared above both that same sort of code and confirmed that there is NO bug of this sort in any version of CF that I tried. If you only created that bug out of kindness to dmerrill, I'd argue it's a mistake, because the bug report implies (even says) "all users will encounter", which is not true.

As for the problem you're having, dmerrill, as I have said from the outset, it seems you have some problem in your setup of CF. You propose now to revert a vm. that's an option. There are others.

First, you could also just uninstall/re-install CF (perhaps saving off the neo*.xml files to compare later and perhaps recover admin settings you may lose). 

Second, I realize you have tried to uinstall the updates and that has "not worked",  but you could more carefully try to run the updates manually, or there may be more information available to help explain if/why that did not/would not work

I know you feel the "server is hosed" (though it's just CF), and that CF won't run anything, etc. I don't think it's so far gone.  I help people through problems like this all the time. It's often just a matter of connecting dots, which you may be missing (and we may not be able to elaborate completely here).

If you want to avoid the need to revert your vm, I am willing to bet that in less than 15 mins we may be able to get this solved, if we do a direct screenshare session together (more info on my site, via my signature). Even if we spent a half hour, if we don't resolve it, you don't need to pay for the time.  I am available right now and the rest of the afternoon, or even this evening, if interested.

[dmerrill]

Charlie, thanks so much for your kind offer to parachute in, it's very much appreciated 🙂

I was able to restore the coldfusion directory from a backup, and the server is functional again.

The error I'm seing is this:

  

As you can see, I've intentionally thrown an error.

CF is able to show cfcatch.message and .detail, but cfdumping the exception object shows this error:

The getMetaData method was not found

As you can also see, this is CF 2018,0,10,320417, otherwise known as "ColdFusion 2018 Update 10", according to cf admin. ColdFusion 2018 Update 11 is available, but attempting to install it and then back it out is what left the server unusable. I can try that HF install again, or something else, if folks have suggestions.

It'd also be great if someone could try my test code on 2018 HF10 to see if they can reproduce the proble, but I understand that that's a pain to do.

Here's that code:

<cftry>
	<cfset asdf=qwer>
	<cfcatch>
		<cfoutput><p>ERROR: #cfcatch.message# #cfcatch.detail#</p></cfoutput>
		<cfdump var="#cfcatch#" label="" metainfo="0">
	</cfcatch>
</cftry>

Thanks again Charlie and everyone.

[Charlie Arehart]

dmerrill, very glad to hear that you're back to working again. As for what you show now, that's of course in the debug output (only). That's not the error you were originally reporting, where you couldn't even DO the dump, right? So let's celebrate at least that victory. 🙂

And I can confirm that yes, if I have cf debugging output enabled, I do ALSO see that same indication of the getmetadata not found, in the debugging output, in CF2018 update 10 (or 11). And yes, I used the exact same code. And yes, I see you using metdata="0" (as an attribute to cfdump, which could be set to false also, and whether it was set to that or true, it makes no difference to the "extra error" appearing in the debug output).

As for it being there and perhaps annoying you, I'll note that I do NOT see that extra error in the debug output on CF2021 update 1. (I can't as readily test 2021 without any updates, to know if that was fixed in 2021 or its update 1.) But at least it is fixed, so you won't see it if/when you update.

Hope that's helpful. For others who may see this thread and chime in going forward, pelase do be sure to indicate if you are raising a concern about the cfdump failing (entirely, as dmerril was experiencing at first) or about the "extra error" showing up ONLY in the debug output. 

[dmerrill]

Thanks again for your thoughts Charlie and BKBK, and for confirming that the problem exists and still happens on CF2018 hf11, so I don't have to wonder if getting that installed would fix it. I will try again to install it, but I have more urgent things to deal with in the short run.

Big picture, this app, which is currently in production and doing well on CF9, has various issues on CF2018.

One of them is that errors often show very little information about what the error is and where it occurred. That's why I was drilling on this exception issue, thinking it might be interfering in some way with the app's generally pretty robust error handling.

I've resolved one of the major causes of unreported errors, and at this point, I am seeing error info where I should be, as far as I know, so I can let go of this unless something says otherwise.

Thanks again.

[BKBK]

@BKBKdo I gather that you're able to repoduce this? Which exact CF version?

By @dmerrill

2018,0,11,326016 

[BKBK]

My test code is:

<cftry>
	<cfset asdf=qwer><!--- Deliberately throws an error --->
	<cfcatch type="any">		
		<cfdump var="#cfcatch#">
	</cfcatch>
</cftry>

(Proviso: "Enable Request Debugging Output" switched on in the ColdFusion Administrator.)

The exception 

The getMetaData method was not found

occurs at the line

<cfdump var="#cfcatch#">

and so is a bug.

[Charlie Arehart]

BKBK, please clarify: do you get the error *only* in the debug output?  That's not clear from your "proviso". If so, would you agree that this problem is NOT causing a failure to be able to use cfdump...which is what seemed the problem for dmerril and the OP, Eugene?

I offered quite a lot of clarification on things in my last comment. I just can't tell if you read it, and indeed my final plea. 

[BKBK]

Charlie, my last post, including the proviso, was meant to clarify how to reproduce the bug. To show that all Windows users will encounter it.

@Charlie Arehart : "... would you agree that this problem is NOT causing a failure to be able to use cfdump..."

I cannot assert with certainty that "this problem is not causing a failure to be able to use cfdump". And I say this humbly.

Here are the error messages once again:

Object Exception - in C:/ColdFusion2018/cfusion/wwwroot/workspace/myProject/test7.cfm : line 5

 The getMetaData method was not found.          

Application Exception - in C:/ColdFusion2018/cfusion/wwwroot/workspace/myProject/test7.cfm : line 5

 An exception occurred while calling the function getMetaData.

They suggest that an underlying object misses a method. What impact does this have on cfdump? I don't know.

As far as this issue is concerned, we're just users of ColdFusion as a product. We've found a bug that involves cfdump. We've reported it to the producer, the Adobe ColdFusion Team. It's now up to them to assess the problem and to solve it. That's how I see it.

[Charlie Arehart]

I'll just say that if all this (from you, dmerrill, and originally Eugene) has all along been merely about an issue of extra errors showing in the debug output, then yes I will regard it has having been a collosal waste of time. You and others can disagree.

I had read this from the beginning as being that the cfdump was failing, as in the page was erroring at the cfdump. THAT would be a real problem, of course.

It wasn't until dmerrill showed his screenshot with the debug output last week that it became clear that (at least as of then) he was referring to debug output, and that's when I made/asked this clarification. He's not replied to the past few messages, so we can let him confirm when he gets back if that was also his issue all along. (He was delayed previously in keeping up, which is understandable.)

FWIW, since you wonder "what impact this has on the cfdump", I will report at least that I see nothing different at all in the dumps of the exception (for the examples here) between CF2018 (where the error tracked in the debug output happens) and CF2021 (where it does not). Does that mean there's no possible impact on some specific case? Of course not. I just mean to say that this has seemed to be a lot of "crying over spilt milk" if indeed this comes down to just having been about this extra error in the debug output.

Indeed, let me just say that I have observed such "extra errors" in the debug output for years. It never concerned me, as I never found it to be a cause for concern. I just accepted it as CF having its reasons to internally have had an error that it did not "bubble up" to the CFML level. Nor have I ever noticed any discussion of it as a cause of concern (though I could have missed one).

Someone may well say, "then how can you know if it was NOT a cause for concern?", to which I'd say we're now talking about how many angels can dance on the head of a pin. Some might even call it reductio ad absurdum, but I won't go that far. Let's see if any new info suggests otherwise. 

If nothing else, perhaps your bug report to Adobe will get them to make the problem go away, and then it will no longer be cause for any concern, if it deserves at all to be any now. Grr.

[BKBK]

It bears repeating: the issue does not occur in ColdFusion 2021. We should therefore assume the ColdFusion Team solved it during the move from 2018 to 2021.

[dmerrill]

Charlie, I'm sorry if you feel I was fussing louder than the issue deserved. I certainly didn't mean to take undue attention from more pressing matters.

As I said, I was trying to understand why many CF errors weren't being caught by the app's error handling in CF 2018, when they were in CF 9. It seems reasonable to question an internal exception caused by code similar to some of our error logging code, even if it didn't break the page in this case.

In any event, I truly appreciate your help, and  BKBK's too. And it's good to know this has been resolved in 2021.

[Charlie Arehart]

Thanks, dmerril. The distinction is that it was an uncaught exception in the debug output. That was unclear since the original post 2 years ago, until it became clear last week.

Again, uncaught exceptions in debug output are not unusual in my experience.

The frustration was at that distinction not being made clear earlier. It could have saved lots of discussion and pointed us in a different direction far sooner.

No one who raised the issue need apologize. It's a subtlety that got "lost in the wash", and it's just something we (who provide support actively here) need to watch out for going forward. Speaking of that, I will reply to fellow supporter BKBK's note, next. 

[BKBK]

I'll just say that if all this (from you, dmerrill, and originally Eugene) has all along been merely about an issue of extra errors showing in the debug output, then yes I will regard it has having been a collosal waste of time. You and others can disagree.

By @Charlie Arehart

I disagree. In fact, I consider it a mistake to call an investigation into an exception - any exception - in ColdFusion's underlying Java engine a waste of time. Let alone a colossal waste of time. 

[Charlie Arehart]

As is often the case, we simply see things very differently here, BKBK. And we both think we have something important for people to consider in this matter. Let's leave our words for people to assess. 

At this point, you've opened the bug report for cf2018, and cf2021 has already resolved the problem. It seems we can leave it at that.