Status/Resolution/Reason: Needs Review//BugVerified
Reporter/Name(from Bugbase): Bradley Wood / ()
Created: 04/20/2018
Components: Installation/Config, JEE Deployment
Versions: 2016,2018
Failure Type: Others
Found In Build/Fixed In Build: Final /
Priority/Frequency: Normal / Few users will encounter
Locale/System: / Platforms All
Vote Count: 1
The Adobe war file comes with a CFIDE mapping by default in the neo-runtime.xml file that points to:
C:\work\depot\ColdFusion\cf_main\cfusion\wwwroot\CFIDE
This path does not exist which prevents CFC paths and such that start with cfide from resolving correctly unless there is an alias at the servlet container level to resolve /cfide resource paths. NOTE this is an issue for servlet containers like CommandBox/runwar that have a special resource mapper that allows the web root (base resource path) to be outside of the war. A stock Adobe war "works" on stock Tomcat only because the CFIDE folder is in the root of the war so it gets found there. In CommandBox, the base resource path is not the war so the web root lookup doesn't work and since the CF mapping is broken it cannot be found.
I've also noticed an interesting behavior where hitting the CF Administrator in the URL will "fix" the XML file and the correct path will get saved. That's kind of cool I guess, but I need the wars to be able to start up right off the bat and work.
I'd recommend perhaps omitting that incorrect /CFIDE mapping entirely from the XML files of your WAR distribution and having ColdFusion populate it on first start when it's missing by calculating the correct path. The war has the cfide folder at the same level as the web-inf folder which shouldn't be too hard to find. That should allow the war to work out-of-the-box as soon as it starts up without needing manual adjustments. This will allow ColdFusion to auto-configure its CFIDE CF mapping on first startup based on the location of the war/web-inf so everything still works when the base resource path points elsewhere.
Attachments:
Comments: