I imported the CF2018 setting using CFadmin package manager into newly installed CF2021 and now I'm getting a following error when I try to edit ORACLE specific Datasource. (MySQL and MS SQL are OK)
Element urlmap.servicename is undefined in STDSN.
I recreated one datasource and it seems to be ok, however, I have over 200 DS's that would prefer not to recreate manually. CF is running on Centos 7.9, cf v2021. Any suggestions?
Well, on the surface it sounds like you're saying you have some setting you want to apply to all the DSNs in an automated way. You could use the CF Admin API, which has a CFC and methods for manipulating DSNs, programatically. It's in your instance's wwwroot/CFIDE/adminapi folder, which is under the "cfusion" folder if you have only one instance.
Or someone may point out how all the DSN info is stored in a neo-datasource.xml file, in the lib folder within your instance, such as cfusion/lib. You COULD try to manipulate that by hand, but that can be risky and error-prone. Since you say you have a DSN that DOES work, you could find what differs between the one that DOES and does NOT work, which can be done easily with the right tools. That may readily identify a simple change to be made in the rest. I can help you do that on a consulting basis (perhaps in less than 15 minutes).
As for how it happened, and especially if you need to prevent it happening again, can you clarify a couple of things?
But again, the last set of questions are just offered to try to help solve the root cause problem. I realize you just wanted to somehow tweak the DSNs manually, and so I started with that. Hope it's helpful, and happy to help even today if you want assistance.
Please do let us know how it goes.
thank for helping trouble this.
The intent was not make any modification to the datasources, the task was just to import data sources from cf2018 to cf2021.
I edited the neo-datasource.xml (I backed up xml file and stopped the cf instance first) and made comparisons between the datasource A that was not working and the one I manually recreated B (That is working). There were minor differences, mainly in element order and datasource A had sendStringParametersAsUnicode=NO where datasource B had sendStringParametersAsUnicode=false, however, even after I made those minor formatting changes to datasource A, it was giving me exact error again.
Well, bummer. But I have a few more thoughts for you:
I know it stinks when a problem like this arises...and you don't know what to blame...and you just want the problem solved. I can only offer ideas for you to consider. As always, just trying to help.
So according to the tools I used Red hat extension in visual code, the xml file is valid.
I tried to submit the bug to the URL you provided, with all the required information and I got the error that bug cannot be submitted without any information as to why. Check attachment.
Any other way to report this as potential bug?
You got the "Bug Submission Failed" probably because your session had expired. Try submitting the bug again.
I forgot to mention that those datasources are in fact working, the apps are using them, however we just cannot edit thos sources. Also when you click on verify datasource (Little check mark) it does not do anything, or at least does not give any confirmation message if the source onnected or not. Also we are running on Linux Centos 7.9, we have 5 stand alone network load balancd servers, 4 CF instances per server with about 250 DSN per server.
@dejank52055655 : Element urlmap.servicename is undefined in STDSN.
At first, I thought it was a bug in /CFIDE/administrator/datasources/oracle.cfm. But I can now prove it isn't. 🙂
To reproduce a similar error, simply point your browser to the page http://yourdomain/CFIDE/administrator/datasources/oracle.cfm.
The cause is therefore obvious. The part of your migration script neo-datasource.xml relevant to Oracle datasources has been corrupted. As a result, when you use the script, the ColdFusion Administrator datasource page posts incorrect form data.
In fact, you can see in the picture in your original post that an XML comment tag "<!--" is being posted as part of the Service Name. Such a corrupted form field value eventually causes an error in /CFIDE/administrator/datasources/oracle.cfm.
In short, you have to fix the migration script. Pay attention to the XML elements pertaining to Oracle datasources, to Service Name and to the location of XML comments. It might actually help to delete all the XML comments.
Thanks for the response, there is issue with neo-datasource.xml file. One of my collegues suggested we put in a empty servicename node inside
<struct type="coldfusion.server.ConfigMap"> (Inside this node)
and this resolved the issue. We just have to use CF code to insert the missing element.
I agree this is a bug (https://tracker.adobe.com/#/view/CF-4211297) I submitted it but not response yet.
Thanks for sharing this, dejank. One thing is not clear from your answer here (or in the bug report you created and your first comment there offering this workaround), and I want to offer it for future readers. Please confirm if you agree.
Folks will find that for whatever datasource they are looking at, they will have the var name="yourdatasource" and then that first <struct type="coldfusion.server.ConfigMap"> line right inside of in, then at some point (within that) they will find the <var name="urlmap"> you mention (there may be other elements before it), and then inside of that will be yet ANOTHER configmap line (like you show), which may or may not have other elements inside of it, and it's within THAT that they should add your last 4 lines.
Of course, messing with (even just looking at) these neo*.xml files is challenging because they are not only XML (usually just one big long line) but also "wddx-formatted" XML, making it all the more clumsy. It would help to open the XML in any sort of editor or online tool that can render it into a nicely formatted hierarchical display. (In fact, those on Windows will find that using lowly Internet Explorer does a really NICE job of at least DISPLAYING XML file content in such a hierarchical way.)
You do then have to be VERY careful when editing the file, as the slightest mistake in leaving out a bracket or quote could render it unable to be processed by CF. Indeed, before one does edit the file, they should absolutely make a copy in case they mess anything up, so they can revert to where they started.
And you didn't mention it here, but of course one would need to restart CF after making any such change, for it to take effect.
Hope all that's helpful, for others who may find this and jump to your offered solution.
BTW, you (or someone) had kindly marked my one of my earlier replies as one of 3 listed "correct answers", but I have unmarked it, as it may have some value but really yours is THE answer--and BKBK did indeed point you to that indication in the error of an issue related to "servicename". Those both remain marked as "answers".