Twitter: raymondcamden


Address: Lafayette, LA, USA

Follow up to ColdFusion Axis2 Web Service Issue

08-21-2014 2,874 views ColdFusion 5 Comments

Last month I blogged about an odd issue with Axis2 web services. Basically, the CFC was persisting past the initial hit. Normally CFCs are recreated on every request. This didn't seem to be the case with Axis2 web services.

I filed a bug report for the issue and today I got a response from an engineer:

This is a change in behavior in how we designed the Axis 2 web services support.

In Axis 1, For every web service request we created a new CFC instance and the request was handled by this new instance. That is why the variables always gets re initialized for every request.

In Axis 2, we are creating the CFC instance the first time only. For every subsequent requests the same instance is used. So you are seeing the caching there. A new CFC instance will be created only if service CFC is modified.

Normally if you are deploying an axis2 based aar, in tomcat, you will see the same behavior.

This was a design decision we took. Are you facing any issues because of this caching? Do you have a requirement to use different CFC instances for each web service request?

So, long story short, this is expected. I want to be clear so people understand the issue. This is not like trusted cache, where changing the code doesn't reflect on the server. This is not like the case where you change a method and have to tell CF to refresh the WSDL. No, this is data persistence, as my example demonstrates. In every other case of using a CFC - either via Ajax or WSDL - this is not how CFCs act.

So... um... yeah. I guess watch out for it. Or take the advice I gave on the last blog entry and avoid WSDL like the plague on humanity it is. If you feel like this was a bad design by the ColdFusion engineers, please post your thoughts on the bug entry, not here. (Or both - just keep in mind I've got no power to change things there. ;)

5 Comments

These comments will soon be imported into Disqus. To add a comment, use Disqus above.
  • Steve Seaquist #
    Commented on 08-21-2014 at 6:13 PM
    The same was posted on StackOverflow 9 hours ago:

    http://stackoverflow.com/questions/24313528/cf10-c...
  • Steve Seaquist #
    Commented on 08-21-2014 at 6:46 PM
    P.S.: A little sympathy for the devil (web services):

    If what you need to do is a small in-app callback to display a dropdown of counties after the user selects a state, sure, use JSON or $.load() or whatever.

    What makes XML appealing in the business world is that it has a contract. It's enforceable. If you publish a service with WSDL (XML about the interface) and XSDs (XML about the data transferred over the service), those terms of the service constrain both publisher and consumer. When large sums of money is involved, the people who control the money really, really like that sort of thing. It makes the conditions under which money is committed explicit and deterministic.

    As you know, I can't talk in a public forum such as this about where I work without prior approval. But you know where I work. It's very definitely a business environment, with auditors and lawyers and all that stuff.

    To your readers, yes, I agree. Please avoid web services when simpler solutions are available and suit your needs. But that's not to say that web services have no purpose. When rigor is needed, and errors could have catastrophic consequences, that's where ColdFusion's simple CFC implementation of web services can be a real life-saver.
  • Commented on 08-21-2014 at 8:28 PM
    Fair points there Steve. Although I still hate em. ;)
  • Commented on 08-22-2014 at 5:45 AM
    What a terrible idea. Just because it's by design doesn't make that a good decision. This is not only inconsistent, it is purposely and lazily inconsistent. Maybe Adobe need a refresher course in what makes a language enjoyable to use (aka Good)

    (And yes, I'll be filling the same complaints on the bug)
  • Commented on 11-14-2014 at 11:43 AM
    It's issues like these that stop companies from upgrading, especially in validated environments. Running tests to verify existing code is costly, having to go through and adjust code is even worse.

    An Axis admin setting where you can set the default instantiation behavior with the additional ability to override at the CFC level would have been a better design.