[coldbox:27104] Strange issue with multiple version of ColdBox

A couple of initial questions come to mind:

We are running ColdFusion 11, there is not a CF mapping in the administrator for ColdBox, however there is a 3.5 ColdBox directory in the root. I wonder if it is attempting to resolve /ColdBox and finding the older version first so it is using that?

There is only one ColdBox 5 application running on that instance with a unique name and the other ColdBox 3.5 applications affected also have unique names. The application finds the Bootstrap.cfc but seems to get mappings confused within the framework. It appears only one ColdBox version can run per CF instance.

It appears only one ColdBox version can run per CF instance.

I would disagree with that, having done it a number of times - both on ACF10 and ACF11 - but there is definitely some "bleeding" going on between your applications. That said, there may be something in your configuration that is allowing scopes to overlap, specifically in the mapping of the framework file system. I would definitely suggest moving the v3.5 directory out of the root - especially if you have Wirebox mapping configured from the root downward. If you have "Save class files" checked in the administrator, make sure to clear the directory where those are stored, as well (WEB-INF/cfclasses).

A few other things to check:

1. Directory naming which resolve might be the same or virtual directories which might be conflicting.
2. Any usage of the SERVER scope within the application which might be bleeding between applications
3. The framework mostly "lives" within your APPLICATION scope, so that's the first place to check.
4. Any shared code that is used between the applications which might be maintaining conflicting states ( singletons, especially )
5. Any kind of shared object cache ( e.g. Memcached ) that might have conflicting keys

One thing you also might try is to add an Application.cfc mapping to "/coldbox" for each application.

Keep us posted. I'm very interested to see what you find out.

Jon

There is definitely some bleeding going on but I would assume since ColdBox resides in the application scope it would also respect the mapping defined in the application.cfc. As you see in the image is is switching ColdBox versions in the middle of the request, then switches it back. The particular getColdboxOCM error crashes all applications using ColdBox on that server instance, even the 3.5 applications where the function exists. You can see how this is frustrating because most of these applications have been working fine for years running 3.1, 3.5, and 3.8 on the same instance. Perhaps this was always an issue but there were no major changes in those versions?

Unfortunately moving the 3.5 ColdBox out of the root directory out is not an option because of the number of applications being supported, but this is definitely the architecture for future migrations.

We will continue to review the code and keep the thread posted.

Thanks, Jon!!!

Coldfusion caches the componets, there is an option in the Administration to turn this on or off.

You will need to turn this off for any ColdFusion website that use the same instance of ColdFusion.

yes, defo turn off “component caching” on the admin, it will cause problems just like this. Also, I would really really recommend you not keep any coldbox folder in your webroot, or it will likely cause issues. I don’t understand your reasoning for why you think you need it there. Just move (or rename) it and use this.mappings for those old apps to still find it. Please do those two things and report back.

The application architecture was in place prior to my existence on the project, I am working with what we have :slight_smile: In the future we are migrating to CF2018 and CB5 and can revisit the architecture. From reading the framework code in the bootstrap.cfc is where I initially assumed the issue was because ColdBox was in the root directory. Of course I need to be able to logically expain this to the team.

I can make the recommendation to move the ColdBox directory out of the root but due to how our environment is configured it is not a single process of relocating the folder (we will need to have developer meetings to explain, update servers, plan downtime, etc).

Will keep you all posted!!!

Cf looks in the web root first to resolve cfc paths before mappings, you don’t really have a choice.

https://helpx.adobe.com/coldfusion/developing-applications/building-blocks-of-coldfusion-applications/building-and-using-coldfusion-components/using-coldfusion-components-developing-guide.html

You can’t have a version of coldbox in the webroot and also have mappings you want to override. Show the official docs to your team.

Will do. Thanks to Brad and the community for your support!