Skip to main content
J
justinh94069848
Known Participant
February 7, 2022
Answered

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

  • February 7, 2022
  • 2 replies
  • 532 views

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.

    This topic has been closed for replies.
    Correct answer BKBK
    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
    }
}

     

     

    2 replies

    BKBK
    Community Expert
    BKBKCommunity ExpertCorrect answer
    Community Expert
    February 7, 2022
    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
    }
}

     

     

    J
    justinh94069848Author
    Known Participant
    February 7, 2022

    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

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 7, 2022

    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.

    /Charlie (troubleshooter, carehart. org)
      J
      justinh94069848Author
      Known Participant
      February 7, 2022

      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

      J
      justinh94069848Author
      Known Participant
      February 7, 2022

      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 😉

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices