When we deploy multiple apps on the same server we usually keep the directory structures separate because it gives us more flexibility over which version of core and which version of plugins are used by each app. It’s also a more robust way to deploy your apps because an update to core or a plugin for one app won’t accidentally break another app.
So your applications on the file system might look something like;
and for each application;
/sites/appA -- /farcry "mapping"
/sites/appA/core/webtop -- /webtop "mapping"
/sites/appA/projects/appA/www -- webroot
CF mappings affect the entire server so for CF we’d generally use an Alias (in Apache) or a Virtual Directory (in IIS) instead which can be configured per application.
In Railo/Lucee mappings can be per web context so we don’t have to worry about this when setting up multiple sites (and the mappings are required in this case – in CF the connector has some magic that allows Alias/Virtual Directories to be picked up and used as mappings).
To answer your questions:
We have a few clients that run multiple sites from a single database/application, but this really only works when you’ve got a whole bunch of sites that re-use the same design, minus some logo and colour changes (i.e. the code base is actually identical). They still log on to each site using different domains though, so the webtop isn’t really “shared” even though it’s the same application.
The only common thing I can think of in terms of sharing resources is Perm Gen space, perhaps if all your apps were mapped to the same copy of core then there could be some small benefit, but probably not enough to bother with – I wouldn’t recommend it
We’re thinking of retiring the “directory deployment” option in the next major version of FarCry Core, mostly because we haven’t needed or wanted to use this type of deployment for many years and a refactor of the application startup is in order, and removing support for this could simplify a few things.
If you need to have multiple apps that live in different “directories” but are all served from the same domain I’d recommend something like Varnish of nginx for proxying the requests, it’ll give you more flexibility and also the opportunity to use caching as well.
The alternative directory structure which shares core and plugins might look like this;
/sites/farcy -- /farcry "mapping"
/sites/farcry/core/webtop -- /webtop "mapping"
/sites/farcry/projects/appA/www -- webroot appA
/sites/farcry/projects/appB/www -- webroot appB
However as I said above, this is a much more restrictive way to deploy your apps because you are locking yourself into using the exact same version of core and plugins, and a core or plugin upgrade might be OK for one app but accidentally break another app. I would try to avoid this scenario and go with the method I described at the top of this post