Has anyone had success with the Adobe ColdFusion B...
# cfml-general
l
Has anyone had success with the Adobe ColdFusion Builder extension in VS Code? After a lot of trial and error, and using a previous version of the extension, I was able to get the extension to talk to my local (CommandBox) server and I was also able to indirectly confirm that breakpoints are being set because the request hangs, however the debugging state/information/controls do not appear to populate or respond when the breakpoints are hit. I went as far as to Wireshark the network traffic and I can see that the CF server is attempting to send a good deal of traffic and information, but it doesn't appear to get picked up by the extension in VS Code. Some environment information: VS Code
1.92.2
Adobe ColdFusion Builder extension
1.0.469
. Yes I know this is one version behind, I was unable to get the most recent version to work at all. All the extension actions fail. CommandBox
5.6.1+00618
using a cfengine of
adobe@2021.0.12+330257
Ubuntu
22.04.4 LTS
I suspect it's some specific environment problem (probably Linux) that is causing the issue, and I'll probably be submitting a ticket for it. I thought I'd see if anyone else had hit any similar issues before I gave up and went that route though.
c
Landon, and I help people use it about weekly--including using the step debugging. There can indeed be challenges for some, and I love helping folks overcome them. As for the issue you raise, I haven't seen or heard of that. There can be any of various explanations for that, but not having seen it I can't readily offer a suggestion. Do you have FusionReactor, perhaps? It can help in that you can confirm the communication arriving to CF, and what is being sent back and forth. I get it that you may feel wireshark shows that and more. I'll add that it's possible to configure the CFB extension to log additional detail about the debugger. The docs for CFB offer more on configuring it. And I can help directly, via remote screenshare consulting if interested. But I realize you may not be interested in paying for such help. I suspect it may be tough to get to the solution here. You may want to reach out to Adobe, as they may offer free support including such screenshare consulting.
I want to add also (and decided to break it out of the end of that last long reply): if anyone seeing this is running CF2023, and you find that when stopped on a breakpoint the list of scopes on the top left are never populated, that's a known issue that can be resolved by removing the graphql package (in the CF Admin package manager or using the CFPM cli tool). This is something I've been meaning to blog about, but I wanted share it here if it may help any of those seeing this.
m
I'd love to see more content created talking about stuff like this. With every other language, there is a dozen articles and a video series or a hundred detailing how to setup each tool and environment. There's barely anything for CF. So please keep blogging, write about it everywhere. Make videos. Get it out there.
l
I can definitely see that the traffic is reaching the CF server, and indeed that the breakpoint is being set. What I can't tell is whether the information retrieved is reaching the extension or not. It certainly isn't populating the tool windows/panes. I'll look into those CFB configuration settings for the logging, I don't think I saw that before.
c
Mb, thanks for the encouragement. Now only if something could create the time. :-)
🙌 2
Landon, given the issues you describe, I'd strongly recommend you try things from another machine running vscode. You may have some quirk in your current setup. There are also ways to isolate some things on the current machine, but doing that could be challenging. Just saying that if you got it working on another machine, then you could add things until it matched what you have now, to see when it doesn't work.
d
I wish Adobe would subsidize Charlie, and other folk who are nothing but good for the language— but that's not a new wish, and if wishes were fishes… 🐟😃 (also, I'm just assuming they do not— maybe they do!) but anyways— It could be a communication issue. Maybe the editor isn't listing on the correct socket/port. That's something you can configure with java debugging but I don't know if there's a config option for the CFB extension, nor why it wouldn't be the default. Maybe something is already running on the port or socket? Perhaps RDS issue? Version of java in use?
c
Thanks, Denny. (And no, they do not. My work is like that of an open source contributor, but in terms of sharing info rather than code. :-) As for your observations for Landon, not how he is connecting successfully. It's just some quirk of not seeing the population of some controls in the ui, he says. BTW, Landon, do you see the indicator next to the line of code that it's stopped on a breakpoint? And do you see the widget at the top which spears allowing you to step over/step into, etc? I've assumed you do, and that's why it feels like then some quirk that you don't see the variables and watch list and stack trace, etc. panes on the left.
l
You've mostly described the issue correctly, @carehart, with one distinct difference: I can't see that it's stopped at a breakpoint directly within the editor. The debug controls do appear and I can tell that it's stopped on particular breakpoints indirectly because the browser will halt wherever I have one set. So the "to server" communication is definitely working. However, the line it breaks on is not indicated in the editor, and none of the callstack/variables/etc. are populated. It's like it's asking for the debug information and then either discarding it or failing in some fashion. As I mentioned earlier I can see the traffic coming through Wireshark and it does appear to be all the information it would need (it's a lot!). I was having a colleague try it out this morning and they certainly got closer than I did. We got a local server connected up and displaying things somewhat properly but it was sometimes finicky, losing the debugger session in VS Code, not unsetting breakpoints and getting caught on them when it shouldn't, etc. But it at least partially worked and will be very valuable for many use-cases. We couldn't get a remote server configuration to work at all however (using the same actual "local" server, just configured as a remote server). It would connect fine but breakpoints wouldn't actually be set. It's entirely possible we misconfigured something there when trying various options. On my part I do suspect it's an environment issue of some kind but I'm not sure it's anything I can influence any further than I've already tried. It might just be something baked deep in the extension that I can't quite see. I'm also not using the latest extension version because that failed for me entirely. I will perhaps experiment with trying to get that working and see how far I get. Thank you to everyone for the help!
c
Just to be clear, the debugger does work (completely) and with remote servers. Again I've done it and helped people get it working. There are just a lot of moving parts to get right. As for your scenario, I've seen that happen on occasion (with a working setup), but a restart of cf and vscode sorted it out. I'll assume you've tried that. As for the colleague experiencing wierdness, it's good they got farther. Too bad they experienced what they did. If you get to wanting to have things working (on either) and you're open to assistance, I suspect I could help. You'd not pay for time you didn't value (but I can't offer everyone free help, and I don't work for Adobe). We might solve this in 15 mins or a half hour. I can't promise--but again you don't need to pay for ANY time if you feel none was valuable. That's not how most consultants work, eh? :-) For more on my rates, approach, satisfaction guarantee, online calendar z and more, see carehart.org/consulting .