For a few days now, I’ve been having issues validating the “Server Home” path within VS Code - Adobe Coldfusion Builder Extension when the path is using a Commandbox server. Here is the full path I’m using on my end:
c:\Users\aze\.CommandBox\server\8AF581728159D384F5AFF6B89868A772-API-Projects\adobe-2018.0.13.329786\WEB-INF\cfusion
Is there anyone else running into a similar problem with the newly deployed VS Code Adobe Coldfusion extension? Has anyone found a solution to this issue?
Can you try pointing to just the WEB-INF? Perhaps Adobe wants you to point to the folder containing cfusion
same error. I was able to test with an Adobe Coldfusion installation and it does work fine and defaults to the “/cfusion” folder. Could it be the “.” in the “.CommandBox” path?
Hard to say, I’d reach out to Adobe and see if they can confirm the correct path or provide additional information as to why its not working. I know other people have gotten this working.
I realize this is old, but people may find it searching for the solution. It’s that CFBuilder’s check of that server home folder looks for it to include a jvm.config file in the bin folder under that server home…which commandbox does not have.
If you just create an empty jvm.config in that WEB-INF\cfusion folder (see the original post here), that will allow CFB to let you get past that screen. (Commandbox won’t be bothered by it, and since folks would rarely look into that folder it shouldn’t confuse too many humans. 
)
If Brad or anyone might offer a point of contention on that, do let us know.
Excellent information, Charlie! I don’t understand why Adobe would have forgotten about J2E installations of ColdFusion, but creating that file would not cause any issues for CommandBox-- and of course, the file would not be used for anything.
When this topic came up today at IntoTheBox '24, I happened to notice that this thread is not found via web searches for the error shown in the original screenshot from the OP, AIS. Doh! It’s only there as the image. So here it is in text: Invalid server home
Hopefully that may (in time) help folks more readily find this via web searches or from our internet overlords…er, I mean, AI chatbots.
Perhaps more important (since it seems I can’t edit that post I wrote last year which was marked as the “solution”): note that the empty jvm.config file needs to be created in the WEB-INF\cfusion\bin (I referred to the word bin but didn’t show it in the path. Sorry.)
I wanted to offer a couple more clarifications, in case anyone else finds this 2022 thread and sees my 2023 answer (and 2024 follow-up).
One is that I’ve since found you can avoid the need to create the empty jvm.config–if you make a different choice in setting up the “server” in CFBuilder. The other is that if you DO try my approach, it turns out there’s one more detail to note (if you find it still “doesn’t work”).
1a - So first, what we have been discussing here is what one would see in setting up a CFB “server” when its setting (on its first “general settings” page) for the “Application server” field is its default choice of “cf + tomcat bundle”.
THAT is where I was finding that we needed to create an empty jvm.config in the WEB-INF/cfusion/bin of that commandbox server instance, to avoid the “invalid server home” error.
1b - Well, I learned this weekend that you can ALSO change that value to “other”, in which case one does NOT need to create that empty jvm.config file. It “works fine” without it.
That said, do beware that when you right-click on the server (going to the “CF” extension in CFB, and its “Servers” list), there are fewer options when defining the Commandbox server instance using this “other” approach. But it does “work”.
2 - That said, I do have one more clarification about the approach I offered (for when using that default “cf + tomcat bundle” option).
It turns out that if you have created the server definition (before creating that empty jvm.config), CFB requires that you specify the closing slash on the “server home” value, where you name your commandbox instance’s location. If you don’t add the slash, you will find it STILL complains of “invalid server home”–even IF you HAVE now defined the empty jvm.config.
It’s a bit of an edge case, I grant, but I helped someone who hit it, and I confirmed experiencing it also, so I thought it worth mentioning.
3a - As for why one may bother to proceed with this “empty jvm.config” approach, well, there are two reasons to keep it in mind. First is the fact that it’s what’s needed if you do NOT know/think to change that “application server” field from its default of “cf + tomcat bundle”.
But second, note that when you use this approach, you get the same CFB options for controlling that “server” as would for a “normal” CF instance. These options are reflected when you right-click the server in CFB (and some–but not all–are offered as buttons to the right of the server in the list).
These options include one to launch the CF Admin for that CF instance–which of course the Commandbox statustray also offers. The others are to start/stop/restart the instance–which of course the Commandbox status tray also offers. That said, these 3 features do NOT work (within CFB) for a Commandbox instance.
Anyway, the point is that none of those (start/stop/restart/launch admin) appear if you use that new “other” approach I just discussed above.
3b - One may wonder then: why bother with the first approach (and the need to create the “empty jvm.config” approach, and worry about the closing slash)?
Well, I would just wonder: if these four CFB server menu features are lost when configuring the server using this “other” approach, what OTHER CFB features might be lost? I don’t know. I have only started exploring that new approach.
So again I leave all this for others who may find this thread in the future. I would welcome hearing if anyone discerns any other differences in using either of these two approaches.
BTW, for those who care to go exploring, note that it’s totally ok to have 2 different servers defined in CFB (such as these two ways) which both point to the same CF instance.
(And yes, some will complain “this is just one more reason I won’t bother with CFBuilder”. Our discussion here is not for you, then. The question was raised originally by AIS, and it came up again on the ACF forums this weekend, which is where this additional discovery were teased out. Some folks will be interested to try it, such as to try to leverage some of the unique features CFB offers over other vscode cf extensions. None of this is to knock them, of course. They all have their benefits and challenges.)
