We have a Coldfusion server that hosts multiple applications, all in their own subfolder. Something like:
- /webrootfolder/applicationA
- /webrootfolder/applicationB
Furthermore, on the development server, we have a copy of a given application per developer, each being a Subversion working copy:
- /webrootfolder/applicationA_dev1
- /webrootfolder/applicationA_dev2
- /webrootfolder/applicationA_dev3
Since we are running Coldfusion 7 (with major resistance to upgrading), I find myself stuck as I want to use CFCs in packages. Here are the various issues, attempted solutions and issues with these too:
- Using a relative component name only works if there is a single package, which would make a mess of components in a single folder.
- Using sub-packages works as long as you never reference components in parent packages, which seems to easily happen when extending, instanciating or using a component as a cfargument type.
- Using a full CFC path starting from the root doesn't work with our multiple copies per developer. ** Using a dynamic path with a variable was my solution as of now... until I realized it doesn't work with extends or cfargument type... ** Using server mappings doesn't work in development as we would have one alias per developer copy. I expect the code to be folder-independant. ** Using application specific mappings (defined in Application.cfc) doesn't work because CF7 and not CF8+.
- Creating local dummy copies of needed CFCs and cfinclude-ing the content of the actual CFCs (with relative paths "../../") was my previous solution. It works, but it's so messy having these clones all over. ** Very recently, I have discovered this solution does not always work. Coldfusion gets confused by same-named functions being included in various CFCs apparently.
- Using development Coldfusion servers on each developer's machine, allowing for the application path to always be
/webrootfolder/applicationA(suggested by Mark A Kruger). ** Main issue here would be to convince the computer team to let us install this. It might take a long time, which I fear I don't have. ** There may be other issues with network configuration (giving access to DB maybe, I'm not sure) which will also have to go through the network team and take a while, if it's even allowed.
One website per application / folder - Changing the root
I have taken time to explore the way the websites/applications are configured in IIS 6. After some research, I found out it's possible to create bindings just like what I was used to under Unix/Apache. At the moment, all applications are in their own subfolder of the web root. Aliases are configured, making "domain.com/appA" point to the "/webrootfolder/applicationA" folder, for example. But it is still a single IIS website with lots of sub paths. The Coldfusion root (for CFC and includes) is thus based on the root of that one website (/webrootfolder).
I made a quick test and managed to have a second IIS website on the server, bound to port 8080 (instead of the default 80). I made this one point directly to /webrootfolder/applicationA/cfm (which is really the root of the app). With this, Coldfusion recognizes that folder as the root and instanciating the "Object" CFC looks for it as /webrootfolder/applicationA/cfm/Object.cfc.
This is exactly what we had in my previous job and it worked really well. That said, it was a small company and I fear this solution may have issues. Mostly: how do I point people to this website? Using port binding isn't very user friendly (our users are not techies). Having a specific domain for each application sounds nice but might be costly, especially if HTTPS is involved (or so I've heard). Subdomains might be another solution but seems to have similar issues.
So...
Have I missed anything? Am I stuck with one of the "messy" solutions?
I have access to the Coldfusion admin panel and possibly the IIS configuration, though I'll most likely be limited if a solution affects the paths or URLs of other applications on the server.
I once asked for directions to a fishing lake from an old farmer in southern Illinois. He scratched his head for a moment and then said to me, "Son, you can't get there from here." :) I think you may be in the same boat Leo.
The problem is not packaging, the problem is your SDLC goes against best practice. Any sort of "dev" server should mirror production - something you have already scrambled with your approach. Moreover, it appears that your developers each have a copy of their own code on the dev server. That makes me think back 12 years when my buddy and I, just starting our small dev shop, hosted code on a dev server and developed against it directly - but that approach is not easily sustained and the larger your team the worse it gets as you have found.
What you should do is run your dev server as a mirror of production. Then allow your developers to run the code on their own workstations - local development as we call it. Then you use your source control to handle differences, merging branches etc. In that case each of your developers could use packaging as you intend and these sort of issues go by the wayside.
I realize I'm giving you the solution that "cuts the Gordian knot" so to speak - but it is the right one. I imagine you are wasting some effort and time with the current configuration and I suspect production deployments or even assembling code for QA is a huge challenge for you at the moment.