Connectors, Tomcat, and Lucee vs. ACF

I suspect that I am over-thinking this question but I wonder if anyone can
help clear up my understanding of precisely how Tomcat connects with
front-end web servers (IIS in this case, but the question should apply to
any of them).

We run about a dozen instances of a web app on an Windows 2012/ACF 10
server. On our ACF 10 installs, we set up all of our hosts within IIS, and
then use Bilal’s fantastic AJP connector to plug them into CF. All of the
site definitions are in IIS and there is no tinkering with Tomcat. ‘Stock’
ACF 10 has only one definition:

My understanding of what is happening here is that, because Tomcat has no
idea where out actual webroots are, IIS is either sending the path to
Tomcat to read, or else sending the actual content of the file for Tomcat
to process, and then returning it; either way, Tomcat is unaware that there
are a dozen instances of anything except inasmuch as CF designates
Applications within them, and that’s on the CF level and not the Tomcat
level.

The Tomcat ‘webapps’ folder in the ACF install is empty.

I just installed Tomcat 8.5 and Lucee 5.1 beta (via the custom JAR) on a
dev machine and can get to Lucee admin directly via Tomcat (localhost:8081
in my case). Tomcat was configured according to this guide:

http://docs.lucee.org/guides/running-lucee/windows/installing-apache-tomcat-on-windows.html

If I try to access any of my sites on IIS using the connector, Lucee comes
back with:

Page /foo/index.cfm [C:\Tomcat\webapps\ROOT\foo\index.cfm] not found.

I realize that I can specify host definitions in Tomcat for every one of
our app instances, but I feel like I’m missing something simple that ACF
was doing here:

  1. Is this possible, or do I need a definition for every IIS host?
  2. Why is ACF Tomcat’s /webapps empty? How does it know where to look?

Thank you!

Sam–
Samuel W. Knowlton
Chief Leagueologist
inLeague * @Samuel_W_Knowlton
http://www.inleague.org
Office: 512.814.8022

ACF uses a customized version of mod_jk and operates within a single J2EE “context”. A J2EE “context” is similar to a website definition in Apache or IIS. While this is contrary to the J2EE specification where desperate sites should have their own context, The good folks at Adobe have made it work for them - probably for the sake of speed. It takes time to spin up new contexts for each site on a new server.

The Lucee installer - which it sounds like you used initially - implements not only the BonCode connector, but also the mod_cfml valve, which enables programmatic configuration of new contexts within Tomcat. This is more-in-line with the J2EE specification, but does cost a few few nanoseconds to create a new context each time a new context is detected by mod_cfml on it’s first hit. Understand, ONLY the first hit of a new context is affected by mod_cfml. Once a context is created mod_cfml valve is not present in that new context and therefore does not interfere with subsequent requests. You can read more about how mod_cfml works by visiting modcfml.org.

I should point out that mod_cfml is NOT a connector on it’s own. It’s an adapter, and functions in-line with other actual connectors. Mod_cfml has been tested and works great with mod_proxy_html, mod_proxy_ajp, mod_jk, and the BonCode Connector for IIS.

Hope this helps.–
Kind regards,
Jordan Michaels
Vivio Technologies

----- Original Message -----
From: “Samuel W. Knowlton” <@Samuel_W_Knowlton>
To: lucee@googlegroups.com
Sent: Monday, June 27, 2016 8:36:27 AM
Subject: [Lucee] Connectors, Tomcat, and Lucee vs. ACF

I suspect that I am over-thinking this question but I wonder if anyone can
help clear up my understanding of precisely how Tomcat connects with
front-end web servers (IIS in this case, but the question should apply to
any of them).

We run about a dozen instances of a web app on an Windows 2012/ACF 10
server. On our ACF 10 installs, we set up all of our hosts within IIS, and
then use Bilal’s fantastic AJP connector to plug them into CF. All of the
site definitions are in IIS and there is no tinkering with Tomcat. ‘Stock’
ACF 10 has only one definition:

My understanding of what is happening here is that, because Tomcat has no
idea where out actual webroots are, IIS is either sending the path to
Tomcat to read, or else sending the actual content of the file for Tomcat
to process, and then returning it; either way, Tomcat is unaware that there
are a dozen instances of anything except inasmuch as CF designates
Applications within them, and that’s on the CF level and not the Tomcat
level.

The Tomcat ‘webapps’ folder in the ACF install is empty.

I just installed Tomcat 8.5 and Lucee 5.1 beta (via the custom JAR) on a
dev machine and can get to Lucee admin directly via Tomcat (localhost:8081
in my case). Tomcat was configured according to this guide:

http://docs.lucee.org/guides/running-lucee/windows/installing-apache-tomcat-on-windows.html

If I try to access any of my sites on IIS using the connector, Lucee comes
back with:

Page /foo/index.cfm [C:\Tomcat\webapps\ROOT\foo\index.cfm] not found.

I realize that I can specify host definitions in Tomcat for every one of
our app instances, but I feel like I’m missing something simple that ACF
was doing here:

  1. Is this possible, or do I need a definition for every IIS host?
  2. Why is ACF Tomcat’s /webapps empty? How does it know where to look?

Thank you!

Sam


Samuel W. Knowlton
Chief Leagueologist
inLeague * @Samuel_W_Knowlton
http://www.inleague.org
Office: 512.814.8022


Win a ticket to dev.objective from Lucee via Twitter, see http://bit.ly/1UbTMWj for details, good luck and see you there…

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAO6JaRX2n0wXH9LfLDCV5qP5HT-ocO6jSa14qU54R43M_%2B-JhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.