Skip to main content
N
nasirk
New Participant
August 18, 2008
Question

8.01 WSDL generation: Seems like a bug (Changes Case)

  • August 18, 2008
  • 6 replies
  • 2468 views
I am not sure why this is happening but there there seem to be a change in the way coldfusion is auto-generating a WSDL form a cfc file in 8.01. The WSDL generated from 8.01 seem to be Changing the 'Case' of the properties /Methods contained . which is not a Problem in CF exposed Apps but does cause a lot of headache integrating into Java based app Clients. As the lower to upper and upper to lower case change seem to make the java App client interperate the properties in the WSDL incorrectly due to its Case Sensitive nature.

Has anyone Experienced this or can anyone point to where the WSDL generation could be fine tuned further..

The behavior can be simulated by having the same cfc WSDL exposed in 8.0 and 8.1 environments and by looking at the WSDL generated. Even after Clearing the Cache (cfc-skeletons & cfclasses folder) & Restarting the Service The WSDL seem be displayed with methods and properties having a different case when WSDL is Compared.

Any help or direction to look to would be appreciated
This topic has been closed for replies.

6 replies

D
Dharma2020
New Participant
August 13, 2010

Did you ever find a solution to this? If so, please share it. We are running into similar issue - we migrated our webservice from CF7 to CF8 - and now everythings broken.

Thanks

DK

F
fgwenger
Known Participant
March 11, 2009
Yeah, we tried that (I just tried it again), and it still shows Rc_add_address in the WSDL. Thanks again and feel free to keep making suggestions.
N
nasirkAuthor
New Participant
September 5, 2008
Hmm, update 8.01 = Recode-of code.
This would be ok to do on small size apps ( but again nice to know if it was documented some where about this change)

In larger enterprise size applications. where the wsdl is the only Interface with other enterprise Apps. any un-documented change of behavior is unacceptable. We have had a hugh outage due to the fact of this unexplanied/unexpected behavior that the update has produced which should have just been the update to some bugs as mentioned in the hotfix.

This just adds one tick on the "Why not not use Coldfusion" at enterprise level for the non CF community.. :(

F
fgwenger
Known Participant
January 20, 2009
Did anyone ever come up with a solution for this? Thanks.
N
nasirkAuthor
New Participant
January 21, 2009
Our server upgrades are on hold for months now due to this problem.
Emails sent to Adobe for any sort of response do not seem to be getting anywhere.

A
Anonymous
August 25, 2008
I've concluded that, while it is inconvenient that Adobe has changed this behaviour, the WSDL they are generating is technically correct. Which is to say, if you were to build a consumer for your webservice from scratch, the ColdFusion service will behave as described by the WSDL.

Bottom line: You have to re-build any consumers which can't handle this change. Preferable re-code them so they still work if the WSDL changes in future.
N
nasirkAuthor
New Participant
August 20, 2008
To Simulate this Behaviour:-
step 1) Sample Files as below put under a folder \XYZ\
step 2) generate WSDL seperately from 8.0 and 8.01 using (http : //127.0.0.1/XYZ/test.cfc?WSDL)
step 3) Compare Diff betweeen WSDL.Case change will be evident.
A
Anonymous
August 19, 2008
I have having the same problem, where the complexType names and the portType names now have their first letter uppercased. The unpatched CF8 (and CF7) used the same case as the underlying CFC filenames.

This is annoying because I have several installations of my web service deployed to clients and when they choose to update their CF8 version they will break their connectivity with yet another third party who is running a java-based (case-sensitive) consumer. My current advice to them would have to be "don't run updater 1".

Does anyone have a fix? Is it possible to create a static WSDL somewhere for the time being until Adobe can address this issue?

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