Skip to main content
Inspiring
May 15, 2017
Answered

ColdFusion 11, Update 12 breaks Flex remoting in some cases...

  • May 15, 2017
  • 3 replies
  • 5035 views

I have an Adobe Flex app that I've written, and of course I occasionally need to call remote procedures on the server sometimes.  We use ColdFusion 11 on the server-side to handle these remote calls.

When I install Update #12 on ColdFusion 11, I get the following error when I make a remote call:
faultCode:Client.Message.Encoding faultString:'Creation validation for class 'flex.messaging.io.ObjectProxy' failed.' faultDetail:'null'

It only seems to happen when I send a complex data-type (like an Array of Objects) to the remote function.  It doesn't happen when I'm just sending strings.

Also, I'm using a secure channel when I make the remote call -- don't know if that might be the difference or not.

Please let me know if I can provide any further information to help track down the root of this issue.  I'm happy to provide any logs you might need, or whatever.  Just let me know.

Thanks,
Laurence MacNeill
Ball Ground, Georgia, USA

This topic has been closed for replies.
Correct answer Laurence MacNeill

This is *STILL BROKEN*.  We just attempted to install Update 13 for ColdFusion 11, and it causes the same error.

When will this be fixed?  We need Update 13 so we can be PCI-compliant, but then we can’t do anything with our Flex apps...  An unacceptable situation.

I have looked at the bug-tracker here: Tracker

But nothing has been done.

When will this be fixed?!!  It is quite urgent!!


I have discovered a work-around...

BTW, Update 13 still has this issue...

The issue only seems to occur if you pass an ArrayCollection from Flex to a function in a .CFC file on the ColdFusion server.

If you pass in an array of strings, for example, it doesn't happen.

If you pass in a complex object that is pre-defined in a CFC file ( a "value object") this issue doesn't occur.

Thus, if you stringify your ArrayCollection (via a JSON Serializer, which can be obtained from a 3rd party, found with a simple Google search) this issue will not occur.  Your receiving function in your .CFC file will need to be changed, of course, to accept a string instead of an array.  You can de-stringify it once you've got the data in your .CFC's function.

Hope this helps.  It'd be real nice if Adobe would simply fix this bug and let us pass ArrayCollections, but until then, use JSON.

3 replies

AlHolden
Inspiring
January 19, 2018

I've been waiting for some resolution to this since last July. We do not compile our Flex source for the Flash player. Rather, ours is a desktop application which runs under the AIR platform in a closed network. We've been update-less since last summer, please don't tell the bad guys.

I agree with Charlie's line of reasoning (something 3rd party was updated, not intentional CF engine change by the CF team). But in addition to Tomcat, I would also check the other Java libraries that are more specific to the "native" RO calls handled by flex_gateway (like BlazeDS), and see if some version trial and error could be done there.

Al

Participating Frequently
December 10, 2018

If you're still looking, the <validators> "fix" is at Tracker  worked for us.

Peter

AlHolden
Inspiring
June 15, 2017

On Charlie Arehart's advice, we also checked our update logs to insure that there were no problems with the update process.
How to solve common problems with applying ColdFusion updates (in 10 and above) - Charlie Arehart's ColdFusion Troublesh…

Inspiring
June 15, 2017

And I assume you found no problems, or else you would've mentioned the problem(s) you found, yes?

Thanks,

L.

AlHolden
Inspiring
June 16, 2017

Yes, sorry. Our log showed everything was successful in applying the update.

So a partial or failed update was not the reason for our encoding faultString bug.

AlHolden
Inspiring
June 13, 2017

Laurence, did you ever get an answer or fix for this?

Our test server was just updated to this patch and we are experiencing the same error.

Inspiring
June 13, 2017

Unfortunately, no.  The only "solution" was to uninstall Update #12, and go back to Update #11.  The only good news is that uninstalling Update 12 was easy and went through flawlessly.

Wish I had an answer for you.

Thanks,

L.