Getting odd error on createObject 'The value of CLASS attribute is invalid.'

[justinh94069848]

Hi Community,

Hopefully someone has seen this before. I have a line of code this is actually in several applications and has never causes problems before. The line of code causing the error is below. This is pretty basic stuff. Creating a object from a SOAP enabled website (it's actually a ColdFusion website from a cfc).

var webservice = createObject("webservice", arguments.url);

The plan for this morning is to recycle (restart) the server and see if that fixes it. If this continues to come up, has anyone seen or fixed this? The server is CF 2018, with the latest patches applied.

[Charlie Arehart · Accepted solution]

Someone may offer a different solution, but I don't recognize that error readily, so here's how I'd go about debugging the issue.

Before concluding something is broken in CF (that a CF restart will fix), perhaps the problem is instead due to a change in the URL you are calling, in arguments.url. Before you may say "nothing has changed in the code that's failing", I don't just mean the VALUE of that URL (though you should confirm that).

Instead, I mean it could be due to a change in the server that's serving that URL. And that can range from a change in its behavior as a web service to a change in the nature of its support for ssl/tls, if it's an https url. Let's consider each in more detail.

First and foremost, consider that CF has long had a behavior (since CF6 introduced web services support, in 2001) where CF will cache the web service definition, in terms of the creation of the underlying java "stubs" for that web service. Sometimes, when a web service changes, you need to do is tell CF to "refresh" that, recreating its stub.

You can do that via the CF Admin on the "web services" page, or you can do it in code on a cfinvoke or cfobject/createobject using a refreshwsdl attribute/argument. You'd want to beware leaving such code in place permanently, as then every call would refresh it, which would be counter-productive if the wsdl is NOT changing. I have a blog post with more on this:
https://coldfusion.adobe.com/2019/06/may-need-refreshwsdl-calls-web-services/

And in that post I explain this briefly and the point to other posts I'd done in the past with more detail.

If somehow that's NOT the solution, there are then a few things you can do diagnostically, to help yourself or help us in helping you. :

1. First, do something to confirm the exact url in that variable (don't trust what you "know" it to be). Either write it out using cfoutput/cfdump/cflog, or perhaps you have CF debug output enabled.
2. Next, visit that URL in a browser (any browser, anywhere). Does it return XML? It should, if it's meant to be called via CF as a web service. (Some servers will return an HTML page if you call a wsdl url, offering it as a way to introspect that web service.)
3. Next, visit that URL in a browser ON THE SERVER, assuming you are able to. It could be that you'd see a different result ON the server compared to OFF. You want to find out if that's the case.
4. Create a cfhttp call to that same url, and run it, dumping the cfhttp scope after. What do you see in that? Again, it should be the XML/wsdl returned from the web service. And if somehow you test this first from someplace other than where your code above is running (like your local dev machine as opposed to the prod server), run the cfhttp code on the prod server, to see if there's a different result.

Let us know if any of these help you.

[justinh94069848]

Hi Charlie,

Thanks for responding so quickly. A few things I didn't share was that my application uses FW/1 and that yes the component is cached by ColdFusion. The service restart did not help, however you are correct in that flush=true (or forcing FW/1 to re-cache the components did fix the isssue.

The interesting thing is, the webservice has not changed. Again, there are other applications that use the same webservice and code that were not failing this morning.

Thanks again,

Justin

[justinh94069848]

Sorry I meant to say "reload=true", in order to force FW1 to reload the components. I haven't had my second cup of coffee yet 😉

[Charlie Arehart]

Glad you got things sorted, and thanks for marking my first reply as the answer--but for now it seems your app reload was the ticket.

Given that, I wonder then: was this error message you quoted really in response to that createobject call alone? I am now suspecting it was not, because really, I don't see how reloading fw/1 would change how ths web service itself is cached. I don't think it's injecting itself into what CF does (I realize it DOES inject itself into the flow of control for your app). 

And sure, since we can see the var keyword telling us this code was in a method in a CFC, it could be that the CFC instance was stored in a shared scope, such that even even changing the code to force the wsdl refresh wouldn't have executed, such that reloading the CFC (the app, the fw) was needed anyway. And in doing that it could have cleared out an error also "cached" (as it were) with the CFC instance. 

Anyway, all this may be moot: your problem is solved and that's what matters most. And you may be unable to recreate the problem, to affirm any of the above. Thanks for the update. 

[justinh94069848]

Here's a bit more into error message.

Detail: It must be a non-zero length string.
Message: The value of CLASS attribute is invalid.
coldfusion.tagext.lang.ObjectTag$InvalidClassException: The value of CLASS attribute is invalid. at coldfusion.runtime.CFPage.createObjectProxy(CFPage.java:8560) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8550) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8495) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8423) at coldfusion.runtime.CFPage.CreateObject(CFPage.java:8364) at

The next part of the stack trace does reference the function that is called six lines down. That function has not changed in months however. Plus this component is re-used in other applications with FW1 and those applications were fine this morning.

You have a much better working knowledge of how ColdFusion works under the hood than I do. If any of that make sense, I'd love to hear your ideas.

[BKBK · Accepted solution]

var webservice = createObject("webservice", arguments.url);

That line is NOT the cause of the error. The cause is: the value of arguments.url is an empty string.

That is, the url variable, which comes in as an argument of a function, has the value "". To confirm that, you can easily reproduce the error using:

<cfscript>
try {
	arguments.url="";
	webservice = createObject("webservice", arguments.url);
} 
catch (any e) { 
	writedump (e); 
}
</cfscript>

There are 2 common ways to prevent such an error:

(1) Give the argument a default value

functionName (string url="some.web.service.com") {
    var webservice = createObject("webservice", arguments.url);
    ...
}

(2) Validate the argument

functionName (string url) {
    /* 
    A more robust alternative: 
    validate using the Regex of a valid web service URL
    */
    if ( len(trim(arguments.url)) > 0) {
        var webservice = createObject("webservice", arguments.url);
        ...
    } else {
        // Handle the error
    }
}

[justinh94069848]

BKBK,

You are probably right. We load the URL from a configuration file. The logs show the configuration file was loaded succesfully, but perhaps something failed. The odd thing is, the configuration file is loaded on application start so you would think restarting the ColdFusion service would have fixed it, but it wasn't until I reloaded the cached components that the application was fixed.

You make a good point about error handling, and I think we can alert the user upstream that the application failed to load properly, and we can send out emails to our support staff.

Thanks,

Justin