No worries Gavin. Thanks for all your help in explaining things.
If nothing else, I’ve found that I can move the web context directories outside the site folder themselves so I can still perform rename operations on the sites themselves without restarting. While it might still make more work for the server that’s not necessary, at least we can keep pushing forward.
Questions are all good, its how we learn, and I admit, I haven’t dealt with IIS with Tomcat, so I’m not sure I am much help here.
I haven’t touched that Connector in a while… maybe someone that does use it can help.
Gavin,
I’m going to end up showing my limited understanding of Tomcat here, so I apologize if I’m asking very simple questions.
I’ve changed the default context so a Web-INF is created outside the website folders. For our environment, we store the sites in C:\Websites. So the default context path is now set to C:\websites. We use IIS with the Boncode connector and when we create our sites in IIS (they’re all created programmatically) the mappings to Tomcat are already created somehow, so we don’t have to mess with setting up any Host Contexts. I guess my question to you is how do we set it up so when we create a site in IIS the context defaults to the WEB-INF inside C:\Websites? I don’t see any VirtualHosts setup in our server.xml file for Tomcat. Somehow Tomcat is becoming aware of the sites that are created in IIS but I’m not sure how.
I can see in tomcat/conf/Catalina that a directory is automatically created for each site and inside the directory, there’s a Root.xml file containing a context pointing to the website directory. I would assume something has to change with the Bonecode connector?
Again, sorry if I’m asking very basic questions.
Adam
On Monday, February 9, 2015 at 2:19:24 AM UTC-5, Gavin Pickin wrote:
Not sure why - but this didn’t send from my email 
Ok… anyone want to know how to achieve this Apache and Lucee?
I played around, did some testing, and this looks pretty solid.
Funny, its almost exactly what I do… just didn’t think about it.
If anyone has any issues with this, let me know, otherwise I’m going to tidy it up, Blog it, and we can add it to the Wiki.
The solution is the same in the server.XML as for Nginx earlier, but I’ll repeat it for completeness sake.
Name which Host Context will be your catchall, by setting defaultHost in the Engine element
That means any URLs coming into Tomcat, that do not match a specific Host context, will use “catchallHost”
So lets add the Host element to our server.xml. You could use the default, but I would rather use a fresh one and invalidate the other one, just in case.
The docBase is the key here. From Apache you will pass a RELATIVE path based on this.
You could just map it to /www or /home/websites or c:\webs or whatever is relevant for you.
Just remember, it has to be a PARENT folder of all of your sites… you could add alias context paths for a complicated set of directories, but lets keep it simple.
Now, in my blog posts, I change my ports
So AJP is 8024
HTTP is 8504
Shutown is 8004
Now, in apache, I would usually have this code, based on the AJP protocol.
<Proxy >
Allow from 127.0.0.1
ProxyPreserveHost On
ProxyPassMatch ^/(.+.cf[cm])(/.)?$ ajp://localhost:8024/$1$2
What this does, it match everything with cfc or cfm or cfml, and then proxy to ajp localhost 8024… and tack on the matches.
If I do this now, it will match the /www from my context above.
I would normally add a Host context with a matching name, like the following
And that would pick up that Host and display it correctly.
This is our issue.
But by removing that Host Context, we can use the main context, and just adjust the ProxyPass
We change it to look like this… where we pass the Relative Directory from the main Host Context or /www
<Proxy >
Allow from 127.0.0.1
ProxyPreserveHost On
ProxyPassMatch ^/(.+.cf[cm])(/.)?$ ajp://localhost:8024/ITB2014-Meet-The-Family/$1$2
So now it works, and it works great.
The full request flow.
So apache sees a domain like meetthefamily.local.com, matches the Servername and pulls up the Apache Virtual Host… like this.
All non cfml resources are served from Apaches DocumentRoot
<VirtualHost *:80>
ServerAdmin gpi...@mydomain.com
DocumentRoot “/www//ITB2014-Meet-The-Family/”
ServerName meetthefamily.local.com
<Proxy >
Allow from 127.0.0.1
ProxyPreserveHost On
ProxyPassMatch ^/(.+.cf[cm])(/.)?$ ajp://localhost:8024//ITB2014-Meet-The-Family//$1$2
The ProxyPassMatch looks for all CFML requests and then passes it to Tomcat’s default Host, and looks inside the WWW folder (root) for the relative path, in this case ITB2014-Meet-The-Family
Of course, if you want a separate Host Context for given apps etc, you surely can.
Since you are still using the AJP etc, you could setup a cluster of instances, and pass the path down too.
I am going to have to experiment with that more.
Simple, and no more stopping and starting Tomcat anymore.
BEAUTIFUL 
I am glad I subscribed to get every post to this group… otherwise I might have missed this.
Very cool.
Gavin Pickin
http://www.gpickin.com
On Friday, February 6, 2015 at 11:03:08 AM UTC-8, Adam De Lay wrote:
Denny,
An installer that will configure a single-instance would definitely been needed in our environment. All of our sites have the same configuration. Right now we host over 2400 sites on 15 servers and we’re trying to figure out if Lucee will be a viable option for us to migrate to.
Adam De Lay
On Friday, February 6, 2015 at 1:18:32 PM UTC-5, Denny Valliant wrote:
On Fri, Feb 6, 2015 at 10:49 AM, Nando Breiter wrote:
Adam,
I’ve recently switched to using Nginx in front of Railo / now Lucee, and found you can configure multiple sites to use a single WEB-INF directory. I didn’t have to restart Railo each time I added a new site this way, and I assume the same would be the case if you rename them.
…
Ha! I knew somebody had posted this solution recently! You can do the same thing with Apache.
The new installers are bundling NGINX as the default webserver. You can sill choose to connect to Apache HTTPD or IIS (that’s the bit that’s taking some sussing) but having a bundled front-end webserver makes a lot of things easier (and NGINX is only like 1-5 megs).
This is an interesting topic, as it’s one major difference when porting apps-- Lucee will make contexts for each site, which is generally a Good Thing™, but not so much when your application is handling 50+ domains, as each one will get it’s own web context-- which is generally not what is intended in those cases.
We could add an option to the installer to automatically set up “single instance” installs, which is what I’d tentatively call what Nando is doing here. We’d need to make it clear /when/ to select that option, but I know several people have tried to port their apps and been sad when it appeared that the new engine couldn’t handle the load, when in fact it can handle like twice the same load, when configured properly.
This brings restart-less domain adding, and eliminates the need to re-configure the webserver or the servlet container, which is also generally needed when your application is handling the domains itself, depending on how you’ve set things up.
There are plusses and minuses to this approach, but it’s generally the only way to handle hundreds of domains without clustering or vertical scaling.
-Den*
–
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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6724d886-6018-4dc9-94ce-d8efa73f5fb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
