Rename site without restarting Tomcat

dev google-group-archive
1

I’m investigating changing our environment from ACF to Lucee. We have
customers that occasionally need their domain name changed and each time I
try and rename the website directory, I get an error that something has a
file open inside the directory. I’m not very familiar with Tomcat, but
here’s what I know.

A Web-INF directory is added to each site directory which contains
references to site/server level configuration. I’ve re-enabled the Tomcat
Virtual Host Manager in an attempt to remove the Web-INF directory before
the rename and it only seem to work after I restart Tomcat. I used Process
Explorer to figure out which file is still open and it seems to be
Web-INF/context/lucee-context.lar (which seems to be an archive file?).

I’ve tried enabling the context option of antiResourceLocking=“true” but
for some reason it seems to create a copy of the entire site in tomcat/temp
and the files don’t update unless you restart Tomcat.

If we end up switching to Lucee, we can easily have several hundred sites
on a server and restarting every time we have a rename just cannot be done.

Any help anyone can offer would be greatly appreciated.

Thanks,

Adam De Lay

2

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.

In server.xml, I changed the default value of defaultHost from localhost to
a name of my choice:

and then defined a host for it within this engine block, setting the
context docBase like so:

  <Host name="mydefaulthost" appBase="webapps">
    <Context path="" docBase="/var/sites/" />
  </Host>

and restarted Railo to pick up the changes.

And then the Nginx configuration for each new site simply needs to include
the subdirectory beneath the docBase directory, something like this:

upstream lucee_servers {
server 127.0.0.1:8888;
keepalive 32;
}

server {
server_name .yourDomain.com;
listen 80;
root /var/sites/yourDomain-com;
index index.cfm
location / {
proxy_pass http://lucee_servers/yourDomain-com/;
}
}

Dots in directory names can be problematic when resolving dot delimited
paths for CFC locations, so I’ve avoided using them in the example above.
The trailing slash in the proxy_pass directive value is necessary for this
type of configuration (running through the defaultHost context). If you set
up a host for a given domain in server.xml, then Lucee will create a
separate context for it, a separate WEB-INF directory, and you’ll need to
restart Lucee to pick up any changes (and in this case, the proxy_pass
directive would be configured like this for the domain: proxy_pass
http://lucee_servers http://lucee_servers; no trailing slash, without
the subdirectory.

If you are interested in going down this path, this blog post might help
get you started.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamediaOn Fri, Feb 6, 2015 at 4:23 PM, Adam De Lay <@Adam_De_Lay1> wrote:

I’m investigating changing our environment from ACF to Lucee. We have
customers that occasionally need their domain name changed and each time I
try and rename the website directory, I get an error that something has a
file open inside the directory. I’m not very familiar with Tomcat, but
here’s what I know.

A Web-INF directory is added to each site directory which contains
references to site/server level configuration. I’ve re-enabled the Tomcat
Virtual Host Manager in an attempt to remove the Web-INF directory before
the rename and it only seem to work after I restart Tomcat. I used Process
Explorer to figure out which file is still open and it seems to be
Web-INF/context/lucee-context.lar (which seems to be an archive file?).

I’ve tried enabling the context option of antiResourceLocking=“true” but
for some reason it seems to create a copy of the entire site in tomcat/temp
and the files don’t update unless you restart Tomcat.

If we end up switching to Lucee, we can easily have several hundred sites
on a server and restarting every time we have a rename just cannot be done.

Any help anyone can offer would be greatly appreciated.

Thanks,

Adam De Lay

–
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/63083509-e7f7-4cc2-a320-ea575964c5f4%40googlegroups.com
https://groups.google.com/d/msgid/lucee/63083509-e7f7-4cc2-a320-ea575964c5f4%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

3

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*On Fri, Feb 6, 2015 at 10:49 AM, Nando Breiter wrote:

4

I will experiment with this and apache… I know adding Apache confs is one thing, but messing with Tomcat confs as well is a big downside for most people.
If it could be MORE LIKE ACF with that respect, it will pick up a lot quicker.

If anyone has any links / resources that might help, let me know.
I’ll blog the whole thing when I’m done.

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.comOn Feb 6, 2015, at 10:21 AM, denstar <@denstar> wrote:

Technically, with the setup Nando posted you do need to configure the webserver, but with some rewriting you can eliminate that need as well, though it will screw with cgi.script_path and such, so isn’t code-neutral like adding a domain/vhost to the webserver is (as this example does).

-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+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/CAOe-Q13F2_-dwa4cmMReSa3aKgAgYDLzGV3dj1KxmRQJcF-%3DTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

5

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 LayOn 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*

6

Technically, with the setup Nando posted you do need to configure the
webserver, but with some rewriting you can eliminate that need as well,
though it will screw with cgi.script_path and such, so isn’t code-neutral
like adding a domain/vhost to the webserver is (as this example does).

-Den*

7

I found a couple of issues.

You need to reset the mappings in the application.cfc

this.rootDir = getDirectoryFromPath( getCurrentTemplatePath() );
this.mappings[ “/” ] = this.rootDir;

Otherwise the following happens.

If you do

Since its not using Apache to resolve that, it resolves to
/www/theflie.cfm

Instead of
/www/MYWEBSITE/thefile.cfm

Same thing with component paths

It seems like it will do relative pathing, so if you are in
/www/MYWEBSITE/ it will walk down to mappingTest/pathCom.cfc

If you are in
/www/MYWEBSITE/test/ it searches
/www/MYWEBSITE/test/mappingTest/pathCom.cfc - not found
/www/mappingTest/pathCom.cfc - not found

If you reset the mapping though, it fixes itself.
In Lucee at least :slight_smile:

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.comOn Feb 6, 2015, at 10:45 PM, Gavin Pickin <@Gavin_Pickin> wrote:

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 gpickin@skiion.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 :slight_smile:
I am glad I subscribed to get every post to this group… otherwise I might have missed this.

Very cool.

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.com

On Feb 6, 2015, at 11:03 AM, Adam De Lay <@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+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/2091e6dd-8c37-4fe8-8986-88e649ac809c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

8

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 gpickin@skiion.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 :slight_smile:
I am glad I subscribed to get every post to this group… otherwise I might have missed this.

Very cool.

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.comOn Feb 6, 2015, at 11:03 AM, Adam De Lay <@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+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/2091e6dd-8c37-4fe8-8986-88e649ac809c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

9

Hi Gavin,

Had a quick scan of this, isn’t this pretty much exactly the same as how
mod_cfml works?

Kind regards,

Andrew
http://about.me/andrew_dixonOn 9 February 2015 at 07:21, Gavin Pickin <@Gavin_Pickin> wrote:

I thought no one had responded, so I blogged about it… but then online I
saw my emails didn’t go…
Here is my blog post is anyone wants to chime in.

http://www.gpickin.com/index.cfm/blog/apache-and-tomcat-save-yourself-the-xml-editing-no-more-tomcat-restarts

–
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/c7299f77-6a90-430c-a8c2-d76e9de1cee2%40googlegroups.com
https://groups.google.com/d/msgid/lucee/c7299f77-6a90-430c-a8c2-d76e9de1cee2%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

10

I found a couple of issues.

You need to reset the mappings in the application.cfc

this.rootDir = getDirectoryFromPath( getCurrentTemplatePath() );
this.mappings[ “/” ] = this.rootDir;

Otherwise the following happens.

If you do

Since its not using Apache to resolve that, it resolves to
/www/theflie.cfm

Instead of
/www/MYWEBSITE/thefile.cfm

Same thing with component paths

It seems like it will do relative pathing, so if you are in
/www/MYWEBSITE/ it will walk down to mappingTest/pathCom.cfc

If you are in
/www/MYWEBSITE/test/ it searches
/www/MYWEBSITE/test/mappingTest/pathCom.cfc - not found
/www/mappingTest/pathCom.cfc - not found

If you reset the mapping though, it fixes itself.
In Lucee at least :slight_smile:

11

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.

AdamOn 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 :frowning:

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 <javascript:>
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 :slight_smile:
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*

12

Thanks Gavin. I’m going to look at putting this in place. I’ll let you
know any problems I have.

AdamOn 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 :frowning:

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 <javascript:>
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 :slight_smile:
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*

13

IIS is very different.
Apache has VirtualHosts… in the httpd.conf or other included conf files
Tomcat has Hosts in Server.xml

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.

Sorry…

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.comOn Feb 9, 2015, at 10:01 AM, Adam De Lay <@Adam_De_Lay> wrote:

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 :frowning:

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 :slight_smile:
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+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/6724d886-6018-4dc9-94ce-d8efa73f5fb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

14

IIS is very different.
Apache has VirtualHosts… in the httpd.conf or other included conf files
Tomcat has Hosts in Server.xml

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.

Sorry.

Andrew - mod_cfml does work like this essentially.
I have been answering that question a lot lately, I think I’m going to dig
into this stuff deeper and blog on it all, since there are a few different
ways to skin a cat.
Although, I wish we had a solution to the 404 issue… that’s where I am
really digging right now.On Monday, February 9, 2015 at 10:01:10 AM UTC-8, Adam De Lay wrote:

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 :frowning:

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 :slight_smile:
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*

15

I thought no one had responded, so I blogged about it… but then online I
saw my emails didn’t go…
Here is my blog post is anyone wants to chime in.

16

Not sure why - but this didn’t send from my email :frowning:

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 gpickin@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 :slight_smile:
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.comOn 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*

17

Also, I found that if you do want to create xml host records… you can have tomcat watch files and reload.
I’m going to test this more, maybe tonight, because you can set what files you want tomcat to watch… so I’d like to try my INCLUDE approach, so I don’t have to update server.xml but my inc_lucee_hosts.xml file.

Of course, I want to see if a reload, is as slow as a restart… so i’ll check and see how long it takes for the change to kick in.
If tomcat keeps responding, during reload, that would be pretty cool.

I like having separate contexts, but at the same time… all the restarts can be confusing.
Managing the context is easier with some tools and automation, if the reload works, I think this is even better than the proxy solution.

Good news is, it would work easily on IIS too… since the solution is in tomcat, so you don’t have to complicate the IIS settings at all.

I’ll report what I find out.
I’m glad some experienced people like Jordan are sharing, its hard figuring this all out on your own… it is much appreciated.

Thanks

Gavin Pickin
@Gavin_Pickin
http://www.gpickin.comOn Feb 10, 2015, at 7:04 AM, Adam De Lay <@Adam_De_Lay> wrote:

No worries Gavin. Thanks for all your help in explaining things.

Jordan, thanks for the information. I will definitely dig into modcfml.org.

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.

Adam

On Tuesday, February 10, 2015 at 4:47:51 AM UTC-5, Gavin Pickin wrote:
IIS is very different.
Apache has VirtualHosts… in the httpd.conf or other included conf files
Tomcat has Hosts in Server.xml

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.

Sorry…

Gavin Pickin
gpi...@gmail.com
http://www.gpickin.com

On Feb 9, 2015, at 10:01 AM, Adam De Lay adam.n...@gmail.com wrote:

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 :frowning:

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 :slight_smile:
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.

–
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/bc94c4d7-9e8c-460c-b637-1a38d94ae971%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

18

No worries Gavin. Thanks for all your help in explaining things.

Jordan, thanks for the information. I will definitely dig into modcfml.org.

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.

AdamOn Tuesday, February 10, 2015 at 4:47:51 AM UTC-5, Gavin Pickin wrote:

IIS is very different.
Apache has VirtualHosts… in the httpd.conf or other included conf files
Tomcat has Hosts in Server.xml

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.

Sorry…

Gavin Pickin
gpi...@gmail.com <javascript:>
http://www.gpickin.com

On Feb 9, 2015, at 10:01 AM, Adam De Lay <adam.n...@gmail.com <javascript:>> wrote:

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 :frowning:

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 :slight_smile:
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 <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6724d886-6018-4dc9-94ce-d8efa73f5fb8%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6724d886-6018-4dc9-94ce-d8efa73f5fb8%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

19

Adam,

What you’re seeing is probably the result of mod_cfml, which is installed by default in the Railo & Lucee installers that were produced by Vivio (documentation here: http://modcfml.org). mod_cfml with Railo/Lucee conforms to the J2EE specification that each new host within a servlet has it’s own servlet context. Thus, why you see a new context created for each new domain. These contexts are stored in memory until you restart Tomcat.

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?

mod_cfml & the BonCode connector do this for you automatically. As long as the site is configured correctly in IIS, the site information is then passed by the BonCode connector to Tomcat and the mod_cfml tomcat valve creates a new context for the new site using the information it gets from IIS. The process is described in great detail on the modcfml.org site.

Hope this helps!

-Jordan----- Original Message -----
From: “Adam De Lay” <@Adam_De_Lay>
To: lucee@googlegroups.com
Sent: Monday, February 9, 2015 10:01:09 AM
Subject: Re: [Lucee] Rename site without restarting Tomcat

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 :frowning:

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 <javascript:>
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 :slight_smile:
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+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/6724d886-6018-4dc9-94ce-d8efa73f5fb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

20

I know this is a old post, but did anyone find out the answer about how to add new hosts to server.xml, without restarting Tomcat, on a Windows Server.

My other question is, if I add a new alias to an existing host entry, do I still need to restart Tomcat?
Presumably, only the context [WEB-INF] is stored in memory. Surely, Tomcat looks at the alias entries within each host entry, inside server.xml. If Tomcat reads the file at runtime, then no restart should be required, for new aliases?