If a developer has e.g. 10 sites under IIS in his dev box and he wants to move from ACF to Lucee step by step, e.g. as a first step moving let’s say 3 sites to Lucee, then “by the book” during Lucee installation he should choose “Per site” in order to connect to Lucee just these 3 sites. If you decide to go “by the book” you will lose some days digging, testing and reading a 66 pages of the connector manual.
As I see it’s widely accepted that the “by the book” Lucee “Per site” connection is a complicated process with many disadvantages, although personally I didn’t find somewhere short clear instructions step by step how to do it, in order to make my own opinion. So, in order to setup my dev box with Lucee I decided to not use again “Per site” connections and adopt the “All sites”. So everything below is done with the default “All sites” option.
Also trying to solve my problem I noticed that in server.xml and in section
<Host name="[ENTER DOMAIN NAME]" appBase="webapps">
<Context path="" docBase="[ENTER SYSTEM PATH]" />
<Alias>[ENTER DOMAIN ALIAS]</Alias>
</Host>
the “name” parameter can’t be the “domain”, in any form the developer uses it in URL. For example if he setup the sites in his dev box with same IP (127.0.0.1), no host name, and different ports to indentify the sites, e.g.
Site1 127.0.0.1:50001 (or localhost:50001)
Site2 127.0.0.1:50002 (or localhost:50002) etc
then the “domain” 127.0.0.1:50001 is not accepted as name parameter in host tag of server.xml.
If it is used, and having edit the server.xml try to restart Lucee service, the service SHUTS DOWN. So I guess in the above name parameter only names in “domain looking format” are accepted.
So what I did to solve the problem
- I uninstalled everything of the previous Lucee installation (Connector, Lucee).
- I deleted whatever remained eg “c:\lucee” folder and all WEB-INF folders in the websites’ root.
- I cleared everything with registry cleaner.
- Using “ACF web server configuration tool” I deleted all the connections of ACF to my 10 sites.
- Disabled all ACF services
- Rebooted.
After reboot no Lucee was active (was uninstalled) nor ACF (services disabled), so I could work only in IIS level. I changed the bindings of all my sites in order their identification to not be based on different ports any more. I had 2 options for that in IIS bindings.
Scenario 1 (classic)
- I used the default port=80 for all sites
- In IP address I used different IP for each site like 127.0.0.2, 127.0.0.3 etc
- In host name I wrote a domain format name e.g. site2name.me, site3name.me or whatever
- In hosts.txt I inserted new lines e.g. 127.0.0.2 site2name.me, 127.0.0.3 site3name.me etc
- In IIS I restarted each site.
- I tested that I could see static html pages using these new dev box “domains”. e.g. http://site2name.me/index.htm. All worked just fine.
Scenario 2
- I used the default port=80 for ALL sites
- In IP address I used 127.0.0.1 for ALL sites.
- In host name I wrote 3rd level domain names having as second and first level “dnndev.me”. So the host name for each site was e.g. site1name.dnndev.me, site2name.dnndev.me, or abcd.dnndev.me or whatever like that.
- I wrote NOTHING in hosts.txt
- In IIS I restarted each site.
- I tested that I could see static html pages using these new dev box “domains”
e.g. http:// site1name.dnndev.me/index.htm. Again all worked just fine.
About only creating subdomains on the domain dnndev.me in order to identify sites in a dev box, see more here http://sitename.dnndev.me/index.htm
I used the first (classic) scenario for setting up ALL my sites under IIS.
Then I installed Lucee again with all the default options, including “All sites”. At the end I didn’t run any connector manually, nor edited any xml, settings etc file (server.xml, BonCodeAJP13.settings etc). After the installation I could access cfm pages e.g. http://site2name.me/index.cfm in ALL my sites!!!
Then, I disabled Tomcat-Lucee service, enabled Adobe CF service and using the Adobe web server configuration tool I connected one site to ACF (remember I had deleted ACF connections to all my sites before Lucee installation). The site, let’s say site A, was working just fine as before the ACF connection!!!
CONCLUSION A —> The choice of the default “All sites” option during Lucee installation didn’t affect, block or conflicts on connecting later ACF to some of these sites.
In order to know WHO supports this site (being connected to Lucee AND ACF at the same time), I disabled ACF service, tested the site, re-enabled ACF service, then disabled Lucee service, tested the site again, and re-enabled Lucee service back again. From this test I saw that the site A was serving cfm pages only when ACF service was running. When ACF service was disabled and Lucee service enabled calling cfm page was giving an error message below
Service Temporarily Unavailable!
Tomcat/ISAPI/isapi_redirector/1.2.46
So Lucee had lost its own connection to the site, even when ACF is disabled. It’s not a surprise since after connections have been done, the handler of cfm pages is an internal issue of the web server IIS, and web server does not know and not care which service is disabled or enabled.
I took a look in IIS handler Mappings of this site A and in comparison to another one. let’s say site B, which was one of the “All sites” of Lucee installation and had no connection to ACF. See the image below.
As we see a new record there, for the same script file extension (.cfm, .cfc etc), does not replace an older record for the same extension. So when I connected and ACF to site A the system just appended one more record for the same extension!.
CONCLUSION B —> In IIS web server the handlers and the script extensions have in general a relation of M:N, not 1:N
Obviously conclusion B leads to the question “Which one of the N (=2) handlers has the control on the extension cfm?”
The test I did enabling - disabling the two services shows that in the web server (at least IIS) handler mappings give “real handler role” to ACF when both (Lucee and ACF) have connection to the same site.
But the above phrase couldn’t be a safe conclusion, because I thought that maybe the “real handler role” is given to whatever made the MOST RECENT connection, which in this case just happened to be ACF.
Since Lucee makes the connections to all sites during installation, the only way Lucee connections to be the most recent ones was to …uninstall Lucee again, then make ACF connections to some sites and then reinstall Lucee.
Curious to see what happens, I did it. So uninstalled Lucee, connected 2 sites to ACF and re-installed Lucee. During Lucee installation I noticed that Lucee didn’t ask me to choose the default option “All sites” as it did the first time when ACF had no connections to my sites. Strange ha? Lucee installation does not present at all the option for “All sites” because simply it can’t take handler role on already existing sites connected with ACF. So Lucee would not be reliable to make my wish for “All sites” come true. I confirmed my thought after Lucee installation by calling a cfm page of the 2 sites I had connect to ACF BEFORE Lucee installation. The sites were supported by ACF although the MOST RECENT connection was with Lucee!! Also I noticed that in IIS Handler Mappings Lucee had installed its own records for .cfm and .cfc as always but these handlers had no effect at all although they were the most recent ones.
CONCLUSION C —> Lucee during installation makes connections to all sites BUT in sites where ACF has connections (whatever time point they were made, before or after Lucee installation and connections setup) the handling of these sites remains under ACF. Lucee connections have no effect to them.
TOP CONCLUSION —> So in the typical scenario of a web developer having e.g. 10 IIS sites supported by ACF, and willing to move step by step to Lucee, e.g. to setup 1 of the sites to be handled by Lucee, then 2-3 more etc all he has to do is
- To install Lucee with the default options (he will not see the “all sites” option because at least 1 ACF site already exists), and then
- To disconnect ACF from the site he wants to move to Lucee. Without ACF handler the Lucee handler will take the control of the site.
- If he wants to setup a completely new site under Lucee, all he has to do is to setup the new site in IIS. Lucee handlers will be installed automatically (Amazing!!!).
- If he wants to setup a completely new site under ACF, all he has to do is to setup the new site in IIS, Lucee handlers will be installed automatically as before, and then he has to make an ACF connection to this new site. ACF handler will take the control from Lucee handler.
I think these are extremely flexible and convenient for an easy step by step transition to Lucee, as most of the professional CF developers need.
Two more points
-
After Lucee re-installation I setup an IIS site based on Scenario 2 of IIS bindings (see above), with host name e.g. “site1name.dnndev.me”. Lucee setup handler for it automatically as always and it was working just fine.
CONCLUSION D —> In IIS bindings both scenarios (1 & 2) can be used and be supported by Lucee successfully.
-
Then I setup a new site as I did in the past (localhost:50001). Lucee again installed handler automatically but could not process cfm pages, giving an error message.
CONCLUSION E —> Sites based on different ports can’t be supported by Lucee whenever they had been setup (before or after Lucee installation).
I hope the above were useful and save your time.
Being new in Lucee, if I made any mistake your corrections are welcome.
Thanks for reading
Only one thing I know,
that I know nothing
(Socrates)