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

[nasirk]

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

[healey_mark]

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!

[nasirk]

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.

[healey_mark]

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.

[nasirk]

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.. :(

[fgwenger]

Did anyone ever come up with a solution for this? Thanks.

[nasirk]

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.

[Jim-sama]

I just ran into this recently myself and solved it.
If you look at the docs, you notice a lot of metadata type stuff that you'd normally use for documenting your cfc's cfcomponent tag.
What it doesn't tell you is that this metadata is also used by the wsdl generator to create the service name.

thus, if you have service names changing case in the wsdl, explicitly use the DisplayName attribute to perm set the case.
example below:

[fgwenger]

We have a returntype that is a CFC, and ColdFusion is now title-casing that name. I don't know of any way to apply a "display name" to the function return variable (rc_add_address below becomes Rc_add_address). We are still stuck needing an upgrade, but not being able to without requiring all of our partners to change their code.

[Newsgroup_User]

fgwenger wrote:
>
> <CFFUNCTION NAME="add_address" ACCESS="remote" RETURNTYPE="rc_add_address"
> OUTPUT="FALSE">
>

Shot in the dark here, but can you set the display name in the
<cfcomponent...> tag of the rc_add_address to 'Rc_add_address'?

[fgwenger]

There is a java piece calling the web service, and they are expecting 'rc_add_address' (no capital), and they break when the returntype of 'rc_add_address' is not present (because it's 'Rc_add_address'). Thanks, though.

[Newsgroup_User]

fgwenger wrote:
> There is a java piece calling the web service, and they are expecting
> 'rc_add_address' (no capital), and they break when the returntype of
> 'rc_add_address' is not present (because it's 'Rc_add_address'). Thanks,
> though.
>

Ah, that sounds problematic.

Still shooting wildly in the dark here, as I never dealt with anything
like this, but does setting the display name in the component tag to
'rc_add_address' do anything? Just to try it.

[fgwenger]

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.

[Dharma2020]

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