Can we eliminate double virtual host administration?

[Paul Klinkenberg]

Hi all,

I am starting a new thread for the following question, because my
original "masterplan" mail has a bit too much content I think.

Is there a way to eliminate the necessity of adding virtual host
settings in both Apache/IIS and Tomcat?
And I mean in such a way, that you already have the webserver, and
want to add Railo (with Tomcat) to process cfml.
ACF works like that, and it would be great if we can accomplish such a
thing as well.

How does ACF/Jrun do it? Does it read the webserver's config file?
And is this something that we/I could build, or already exists?
I should be adding this to the JE which will be used for a default
Railo install. That'll be Tomcat right?

I will be able to put some time in this, since it would make Railo
simpler for everyone, which is the masterplan after all :-)

As a disclaimer: I already know about the regex/wildcard host option
for Resin, (and possibly Tomcat as well?), but then you still have
problems with multiple domain names for one host.

Hoping on input, kind regards,

Paul klinkenberg

[Andrea Campolonghi]

Paul 

Not sure what do you mean.

Also with ACF you need to make Virtual Hosts .....

What's your point ?

Configuring the webserver to process cfml. Jordan installers already do that ( using mod_jk ) that I then personally change in favour of mod_proxy.

Andrea

2010/9/9 Paul Klinkenberg <pa...@ongevraagdadvies.nl>

--
Andrea Campolonghi
and...@getrailo.org

[Peter Boughton]

It's been discussed before on this list.

CF/Jrun achieve it by a magic connector, and only having a single context.

None of the Open methods for going from Apache/IIS -> servlet engine
have the "magic stuff" that mod_jrun has.

Also, it would mean losing the benefits that Railo's multiple contexts
can provide.

But yeah, the concept of a single host config, plus being able to link
multiple domains to multiple contexts, is definitely something I'm in
favour of having (as an option; but not as only way), but it's a
question of finding someone with enough experience with JEE and
connectors and so on to be able to create it.

I've still not had a chance to look at Jordan's installers yet - don't
know if that handles modifying an existing setup, or is it only built
for initial install?

[Judah McAuley]

What I think he means is that with IIS I have to define a website, do
hostheader/port parsing and point it at my web root. That's great but
I also have to go into Tomcat's Server.xml file and define my webroot
and hostname/port in there. Furthermore, when I set up more than the
default website you have to add in the virtual directory /jakarta to
your new website and point it at the connector. I don't find it a big
deal and don't mind doing all that (which I don't think is much at
all) but I understand why people would want it to be easier. With ACF,
you add a new website in IIS, point it at your webroot and you are
done.

Judah

[Judah McAuley]

Are there any hooks in IIS7 to catch an event like "on Website
Creation" or something that could then grab the attributes of the new
site and go get the Tomcat Server.xml file and modify it? Sounds a bit
dicey, I agree, but I know nothing of connectors, so that's the best
idea I've got so far.

Judah

[Paul Klinkenberg]

Hmm, maybe I am overlooking something here, since I haven't used the installers yet (I'm on mac).

What I mean, is that if I now have a new website for my server, I need to add that virtual host in Apache's httpd.conf, AND in resin's resin.conf. Especially when that website has multipe domain names, because then Resin's wildcard host doesn't work for the extra domain names.

With ACF, I only need to add it to Apache's httpd.conf.

That's the difference I see, the "double virtual host administration".

Please let me know if I am overlooking something here...

Kind regards,

Paul Klinkenberg

Hoogravenseweg 92, 3523 TN Utrecht
06-47474757 / pa...@ongevraagdadvies.nl
www.ongevraagdadvies.nl / www.railodeveloper.com

[Paul Klinkenberg]

Hi Peter,

I must have missed that thread. That's a shame. There are times like now when I'm addicted to checking the list, and there are times when I prefer to go fishing :-)

Thanks very much for the explanation on Jrun, and too bad to see that technique is not yet available to us.

I am trying to understand what you mean with "... losing Railo's multiple contexts".

Probably I should have some more knowledge of the underlying principles, but could you explain it a bit more? Do you mean the web contexts? I sure would not want to lose that. That would definately be a show stopper.

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[Gert Franz]

Paul,

 

Well there is the third option for the host.xml entry. Check out the wiki here:

 

http://wiki.getrailo.org/wiki/Tips_And_Tricks#Adding_contexts_in_Resin_3.1.9_%28without_restart%29

 

Then you don't have to create any change in the resin.conf and you don't have to restart the server…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

[Gert Franz]

Hmmm…

 

if I read this:

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

and this:

http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic%20Application%20Deployment

I guess even with Tomcat a dynamic context generation is possible. All we would need to do is to trigger any new event in IIS (like creating a new website) and create such a content.xml for it immediately. Then the double virtual host administration wouldn't be necessary anymore…

 

Or am I wrong?

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul Klinkenberg
Gesendet: Freitag, 10. September 2010 00:05
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host administration?

 

Hmm, maybe I am overlooking something here, since I haven't used the installers yet (I'm on mac).

[Gert Franz]

Paul,

 

in our training we stressed contexts enough J

 

A web context is unique for each web root. So data sources, mappings, the railo admin become separated for all virtual hosts. In Adobe CF you DON’T HAVE THIS FEATURE! There everything is in one big context. You need something like the sandbox security which costs performance and money in order to achieve this. And it needs to be configured as well… so not a thing out of the box…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul Klinkenberg
Gesendet: Freitag, 10. September 2010 00:25
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host administration?

 

Hi Peter,

[Judah McAuley]

That looks cleaner than editing the Server.xml file as I was suggesting. I'm still not sure what IIS hooks are available but that has promise I think.

[Peter Boughton]

> Probably I should have some more knowledge of the underlying principles, but
> could you explain it a bit more? Do you mean the web contexts? I sure would
> not want to lose that. That would definately be a show stopper.

Yeah, someone else can probably explain it better, but my
understanding is that Jrun only has a single web context shared across
all webroots.

The security/isolation of Railo comes from using multiple web
contexts, and so doing the exact same thing as Jrun would break that.

I don't know if there's some way to keep the contexts and "extend
backwards" into the web server, which might enable this - but it
currently seems the other ideas people are mentioning -having an
installer or web server trigger to create the config and refresh the
app server - might be a simpler route.

> I must have missed that thread. That's a shame. There are times like now
> when I'm addicted to checking the list, and there are times when I prefer to
> go fishing :-)

What you need is a mobile device that lets you check the list whilst
you go fishing! :)

Anyhow, here's the thread I was referring to:
http://groups.google.com/group/railo/browse_thread/thread/f2834554a16e9bc6/3126f77ae836fdd8

[Paul Klinkenberg]

Hi Judah, and all,

Now that Peter Boughton explained that building a connector with the necessary "magic" is not easy at all, I was thinking of the same as you did, but with a slightly different approach.

I could create a scheduled task, that checks the httpd.conf or IIS config xml for changes. If a change occured, then destillate all virtual hosts from the file, check if any of the hosts have changed, and then update Resin or Tomcat with these changes.

Resin has the feature of rebooting itself if the config file has changed; I don't yet know how that is done with Tomcat, but the rebooting/reloading the config should be done as well.

This way, it could be asked at installation time if the task should be automatically started or not, saying something like "Do you want Railo to automatically update it's settings if you add or change a virtual host in your webserver?" (Whether or not it would ever be in the installer is out of my reach off course)

This way, control of the JEE config file is given to either the end-user or Railo.

I am hoping on anyone's comments, and am starting to feel happy about having possibly found a solution to this question :-)

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[Paul Klinkenberg]

Yeah yeah I know about WEB contexts, what do you think ;-)

I just did not understand why Peter suggested that eliminating "double virtual host administration" would mean there were no more "Railo multiple contexts". I did not think "multiple contexts" meant "multiple web contexts" in his reply. 

I assumed he meant something else, like "multiple instances" or so.

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[I should have answered all the exam questions, shouldn't I?]

Op 10 sep 2010, om 00:32 heeft Gert Franz het volgende geschreven:

Paul,

 

in our training we stressed contexts enough J

 

A web context is unique for each web root. So data sources, mappings, the railo admin become separated for all virtual hosts. In Adobe CF you DON’T HAVE THIS FEATURE! There everything is in one big context. You need something like the sandbox security which costs performance and money in order to achieve this. And it needs to be configured as well… so not a thing out of the box…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

<image001.jpg>

[Judah McAuley]

Multiple instances might auto-configuration of Tomcat kind of gnarly
now that I think about it. How would something looking at IIS/Apache
config changes know which instance to go set things up in? If the
config monitoring tool was tied to an instance of Railo then you could
potentially have multiple tools trying to go and contend for a newly
created website. I don't run multiple instances, personally, but I
could see that be a problem.

Judah

[Paul Klinkenberg]

Looks great!

Now I am not sure about creating a listener for IIS events; imo a scheduled task (or directory watcher!) would be easier, and could handle both IIS and Apache's config files in one go.

I will volunteer to create this app. If anybody has some extra ideas, let's hear it!

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

Op 10 sep 2010, om 00:29 heeft Gert Franz het volgende geschreven:

Hmmm…

 

if I read this:

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

and this:

http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic%20Application%20Deployment

I guess even with Tomcat a dynamic context generation is possible. All we would need to do is to trigger any new event in IIS (like creating a new website) and create such a content.xml for it immediately. Then the double virtual host administration wouldn't be necessary anymore…

 

Or am I wrong?

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

<image001.jpg>

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul Klinkenberg
Gesendet: Freitag, 10. September 2010 00:05
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host administration?

 

Hmm, maybe I am overlooking something here, since I haven't used the installers yet (I'm on mac).

What I mean, is that if I now have a new website for my server, I need to add that virtual host in Apache's httpd.conf, AND in resin's resin.conf. Especially when that website has multipe domain names, because then Resin's wildcard host doesn't work for the extra domain names.

With ACF, I only need to add it to Apache's httpd.conf.

 

That's the difference I see, the "double virtual host administration".

 

Please let me know if I am overlooking something here...

 

Kind regards,

Paul Klinkenberg

<image002.gif>

[Todd Rafferty]

This is Tomcat 7 btw, which is not officially released yet. I don't know about Tomcat 6.

--
~Todd Rafferty ** Volunteer Railo Open Source Community Manager ** http://getrailo.org/

[Paul Klinkenberg]

Yes, I agree that is something I would need to look at, but that will work out fine I'm sure.

I am currently already running multiple instances of Railo/Resin, hooked into one Apache config file. So if the monitoring tool wouldn't provide that, I will get an alert sms within 2 minutes :-P

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[Gert Franz]

Well here weg o:

 

http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

[Gert Franz]

Well much better than a scheduled task would be that the Event of adding a website in IIS would automatic trigger the change…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul Klinkenberg
Gesendet: Freitag, 10. September 2010 00:40
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host administration?

 

Hi Judah, and all,

[denstar]

This is the approach I've taken with cfdistro:

The project drives it all.

More specifically, project properties drive it all.

A script does the actual app server / web server configuration, based
on the values of various properties.

I set these properties in a properties file, and then I type things
like "server.install", or "httpd.host.install" (maybe
"server.httpd.host.install" to do "both" at once... eh, you get the
point). There's even a cheesy bat/sh menu driven deal (eventually
there will be a sweet GUI again).

Projects can share hosts, or have separate instances, or whatever-- it
is all based off of the values of various properties (even better,
it's really easy to have various "types" of builds for the same
project, that all use the same "commands", and whatever you specify on
the command line overrides the values in the property files).

It would be easy enough to hook it up to a cron job / at command for
even more automation, but really the issue here isn't so much
automatically deploying new apps, as it is restarting the server for
new hosts to be deployed, which generally means loosing user sessions.

There are several approaches to mitigate / remove that aspect of the
problem (caches, clusters, separate instances (on different IPs is
best), etc.), but then we're really off in oober-user land. =)

Anyways, for my money, scripts are the way to do lots of things based
off of "one" command, versus "listeners" or scheduled tasks.

I can go into more detail on the specifics of the current cfdistro
implementation, if anyone's that curious.

:Den

--
The thing I fear most is fear.
Michel de Montaigne

[Sean Corfield]

On Thu, Sep 9, 2010 at 1:48 PM, Paul Klinkenberg
<pa...@ongevraagdadvies.nl> wrote:
> Is there a way to eliminate the necessity of adding virtual host settings in
> both Apache/IIS and Tomcat?

If all your sites are powered by Tomcat, you could simply tell Apache
to proxy all requests to Tomcat and preserve host headers. That way
you only have to update Tomcat's server.xml file.

It really depends what you actually need Apache to do for you.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[denstar]

On Thu, Sep 9, 2010 at 10:19 PM, Sean Corfield wrote:
> On Thu, Sep 9, 2010 at 1:48 PM, Paul Klinkenberg
> <pa...@ongevraagdadvies.nl> wrote:
>> Is there a way to eliminate the necessity of adding virtual host settings in
>> both Apache/IIS and Tomcat?
>
> If all your sites are powered by Tomcat, you could simply tell Apache
> to proxy all requests to Tomcat and preserve host headers. That way
> you only have to update Tomcat's server.xml file.
>
> It really depends what you actually need Apache to do for you.

Either way you'd need to HUP (restart) both of 'em, neh? Not that it
matters much with Apache, but servlet containers are another matter.

At least if you're utilizing different Tomcat hosts. Not sure exactly
what the advantage is... I think they still use the same VM, neh?

One of my pet peeves is folk that use the root context "/" for their
app. (99% of folks ;])

Tho Railo seems fine with mapping / to something, in the web context.
Which is super cool, IMO.

:Den

--
The world is but a perpetual see-saw.
Michel de Montaigne

[Paul Klinkenberg]

Hi Denstar,

I am already breeding on a plan for a Railo admin dashboard, ever
since I read your previous mail about cfdistro. I will get back to you
on that. (It's gonna be cool)

I think that your suggestion here is not addressing the question in
this thread. Which is more or less "can we improve Railo in such a
way, that installing it on an existing webserver will automatically
make all websites be powered by Railo, _without_ any extra
configuration".

Kind regards,

Paul klinkenberg

Op 10 sep 2010 om 05:53 heeft denstar <vallia...@gmail.com> het
volgende geschreven:\

[Paul Klinkenberg]

I will start this project on sunday, if you guys also think this plan is a good idea.

Gert,

The IIS event listener technique does not yet take Apache into account.

 

Except for some overhead caused by a directory listener, and a possible delay of a few seconds before the site would be added into the JEE, I do not yet see        why such a directory listener would not be a good approach... Please enlighten me!

 

Kind regards, and great to see you so active on the list :-)

Paul klinkenberg

Op 10 sep 2010 om 01:19 heeft "Gert Franz" <ge...@getrailo.com> het volgende geschreven:\

Well much better than a scheduled task would be that the Event of adding a website in IIS would automatic trigger the change…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

<image001.jpg>

[Gert Franz]

Paul

 

I think a directory listener is definitely something worth investigating. But you need to investigate 2 files only I suppose. And you need to locate them in your application…

 

If you need anything, let me know…

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies      Professional Open Source

skype: gert.franz         ge...@getrailo.com

+41 76 5680 231           www.getrailo.com

 

 

Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul Klinkenberg

Gesendet: Freitag, 10. September 2010 09:24
An: ra...@googlegroups.com

[denstar]

On Fri, Sep 10, 2010 at 12:52 AM, Paul Klinkenberg wrote:
> Hi Denstar,
>
> I am already breeding on a plan for a Railo admin dashboard, ever since I
> read your previous mail about cfdistro. I will get back to you on that.
> (It's gonna be cool)

Sweet!

> I think that your suggestion here is not addressing the question in this
> thread. Which is more or less "can we improve Railo in such a way, that
> installing it on an existing webserver will automatically make all websites
> be powered by Railo, _without_ any extra configuration".

So they'd all use the same instance, but get auto-generated web
contexts per host?

Yeah, I was thinking from the "I don't have any websites besides
localhost, but I want to add http://myapp.internal and have it be
Railo powered".

There's a lot of variables, and not much convention due to that, so...
it's tough to write a general solution. Even with the Adobe
connector, don't you have to add something to each vhost? It's been a
while since I messed with it.

I wonder if we could do something cheesy for Apache and instead of
writing a "real" connector use something like mod_actions?

http://httpd.apache.org/docs/2.0/mod/mod_actions.html

Eh. It's an interesting problem.

:Den

--
There is no desire more natural than the desire for knowledge.
Michel de Montaigne

[Jordan Michaels]

Show me the money Den. I wanna see it. =)

-Jordan

[Jordan Michaels]

Personally, I'm for the "magic" connector approach. In fact, the next
version of the JK connector will probably work how we want it to.

Check out the AJPv13 extensions proposal:
http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html

Under "Proposed add-ons to AJP13", note that it states:
"Extended env vars passed from web-server to servlet engine."

Further down the page, note that these "env vars" include context
information - the kind of thing we currently have to write out when we
modify our server.xml files.

Seems to me this JK connector update just needs to happen before we can
use the JK connector how we want to, and NOT have to update the Tomcat
server.xml file each time we add a new site to IIS/Apache. Note that the
proposal also includes wildcards, like the asterisk: "*".

--
Warm regards,
Jordan Michaels
Vivio Technologies
http://www.viviotech.net/
Open BlueDragon Steering Committee
Railo Community Distributions

[Paul Klinkenberg]

Jordan,

Great research! Off course I would also be much in favor of doing it like that. It's what I actually hoped to hear in the first place :-))

Just because I thought it wasn't yet possible that way, I wanted to take the side-route I proposed to implement it another way.

Without having looked at the proposal myself, do you have any insight in when this new version might come out? (is handy info for me, because then it might save me a bunch of development time)

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[denstar]

On Fri, Sep 10, 2010 at 12:20 PM, Jordan Michaels wrote:
> Show me the money Den. I wanna see it. =)

Money is overrated. You can see the code tho. ;-)

Judah offered to help me suss out the last bits so I can get an
official release out. I'm typing up the details for him, but mainly
it's a matter of naming things (I say, laughing, as that's one of the
Hard Things to do).

:Den

--
There is no passion so contagious as that of fear.
Michel de Montaigne

[Judah McAuley]

On Fri, Sep 10, 2010 at 3:27 PM, denstar <vallia...@gmail.com> wrote:
> On Fri, Sep 10, 2010 at 12:20 PM, Jordan Michaels wrote:
>> Show me the money Den. I wanna see it. =)
>
> Money is overrated.  You can see the code tho.  ;-)
>
> Judah offered to help me suss out the last bits so I can get an
> official release out.  I'm typing up the details for him, but mainly
> it's a matter of naming things (I say, laughing, as that's one of the
> Hard Things to do).

I've spent awhile learning to speak Denstar (or at least understand
it) so I'm going to try and do the final
wrangling/documenting/translating as I can. I'm really looking forward
to using cfdistro as well, so it makes it worth my while :)

Cheers,
Judah

[denstar]

The AJP proposal reminded me of the JBoss connector:

http://www.jboss.org/mod_cluster

Nifty stuff! JBoss is bad ass.

After one major burnage (across several sites at once), I try not to
rely on cgi vars much (specifically script_path). Especially with
rewriting and proxying in the mix and whatnot...

I'm finding URLRewriteFilter, with it's rewriting of incoming and
outgoing links, a tempting solution to a lot of stuff.

Eh.

You don't really *have* to update the server.xml file with every site.
If you deploy your web apps with contexts ("/coolapp"), you can take
advantage of the built-in stuff that all the containers support for
automated WAR un/re/deployment, which leaves you modifying just your
web server*.

The stickler seems to be about adding hosts to the container, which
aren't quite the same thing as hosts in Apache or IIS.

*you can do this with cfml apps that expect to live at "/" with a
mapping for "/", but your HTML needs to be flexible-- not relying on
#cgi.script_path#, for example. Or else you use the outbound link
rewriting power of URLRewriteFilter ;).

Of course, I use the plain old AJP or HTTP proxy stuff in httpd, which
only takes one line to "connect" a httpd host with a cfml application,
versus doing the whole workers configuration stuff and whatnot with
mod_jk (which seems to be the most popular way of connecting on IIS).

So much depends on what you want to do, and expect.

:Den

--
There is no pleasure to me without communication: there is not so much
as a sprightly thought comes into my mind that it does not grieve me
to have produced alone, and that I have no one to tell it to.
Michel de Montaigne

[Jordan Michaels]

On 09/10/2010 03:33 PM, Judah McAuley wrote:
> I've spent awhile learning to speak Denstar (or at least understand
> it) so I'm going to try and do the final

Haha... learning to speak "Denster". =P

Okay cool. I look forward to seeing it!

[Russ Michaels]

You can avoid the host entries with resin like this
http://russ.michaels.me.uk/index.cfm/2010/9/5/Railo-Dynamic-host-configuration

IIS and Apache need a site setup otherwise how would they know what domain name to use, where the site is located, etc etc, but Apache may be able to do something similar to what I did with Resin by using Regex.
IIS comes with scripts that allow you to automate site setup, so you could script everything from a simple form which would save you some time.

Russ

--
---
Russ Michaels
my blog: www.michaels.me.uk
www.cfmldeveloper.com - free CFML hosting for developers
www.bluethunderinternet.com - professional ColdFusion and Railo hosting

[Paul Klinkenberg]

Hi Russ,

Thanks for the tip. Unfortunately, the regex host in Resin doesn't take any extra host aliases into account, and it requires the webserver directories to be setup in a specific manner. So for people wanting to switch to Railo, it might still be some hassle to get Railo going that way :-/ 

Kind regards,

Paul klinkenberg

Op 11 sep 2010 om 10:12 heeft Russ Michaels <russ.m...@gmail.com> het volgende geschreven:\

[Russ Michaels]

having multiple aliases simply pointing at the same site is actually a bad practice for several reasons, it causes SEO problems, stats problems, code issues (due to host name) etc.
The recommended solution is to use a rewrite rules to redirect aliases to the main site, this can be done easily with Apache using mod_rewrite or using ISAPI_REWRITE for IIS, or using the built in rewrite engine in IIS7.
This even applies to using your domain with and without www, you shouldn't have both working, one should redirect tot he other.

Having website directories setup in a standard way is also a best practice and very easy to achieve.

So for most people this should actually work really well, for anyone else, sorry but you have to add host entries :-)

[Paul Klinkenberg]

I understand what you mean, but there are 2 reasons for still doing it: the client does want to have the same site shown with different hosts, and more importantly: applications where the content and layout (or language) is different based on the host header.

Personally I completely agree on the SEO part btw.

Kind regards,

Paul klinkenberg

------------

Dit bericht is verstuurd via mijn iPhone, en is daarom wellicht bondiger dan u van mij gewend bent.

Op 11 sep 2010 om 11:26 heeft Russ Michaels <russ.m...@gmail.com> het volgende geschreven:\

[Paul Klinkenberg]

Hi all,

Yesterday I created an Apache-to-Tomcat-VirtualHost-copier (note to self: find better name), and ran into one problem. In Apache, you can define on which port the VHost is listening. This port setting is not available in tomcat it seems. Now a problem can arrise when you have the following Apache setup:

- all hosts, port 80: directory=/sites/defaultsite/. Here, the default site says something like "only ssl is allowed on this server. Please go to https://...."

- www.site.com, port 443

What will happen (in my tomcat setup) when you call www.site.com:80, is:

- Apache uses the default vhost on port 80

- Apache wants to return the default file "index.cfm"

- Apache sends the request to Tomcat

- tomcat recognizes the host name www.site.com in it's vhosts (meant for port 443 only, but  does not know it)

- tomcat will execute the index.cfm of www.site.com, an return the output to apache

- apache sends the wrong content back to the user :-( 

Does anyone know how I can prevent this from happening?

Thanks in advance, kind regards,

Paul klinkenberg

Op 11 sep 2010 om 15:36 heeft Paul Klinkenberg <pa...@ongevraagdadvies.nl> het volgende geschreven:\

[denstar]

On Mon, Sep 13, 2010 at 2:04 AM, Paul Klinkenberg wrote:
> Hi all,
> Yesterday I created an Apache-to-Tomcat-VirtualHost-copier (note to self:
> find better name), and ran into one problem. In Apache, you can define on

Heh. Names can be rough!

So does it really copy an Apache vhost? Like, parses the config file,
sees a VirtualHost directive, and then parses that to get information?

Or maybe parses the output from -D DUMP_VHOSTS?

You can't be that crazy... :)

> which port the VHost is listening. This port setting is not available in
> tomcat it seems. Now a problem can arrise when you have the following Apache
> setup:

I'm not sure I follow. The port setting isn't available in tomcat?

How are you connecting Apache to Tomcat?

Here's the line from my Apache vhost template that connects it to the
Tomcat server (via mod_proxy http-- ajp13 is almost exactly the same):

RewriteRule ^\/(.+)\.cfm(.+)? http://@server.host@:@server.port.http@@war.contextpath@/$1.cfm$2
[P,QSA,L]

Here "server" referrers to the application server info (tomcat):
@server.host@ is the tomcat host (something like myapp.internal),
@server.port.http@ is the HTTP port Tomcat is listening on, etc..

But you can see that I'm telling it what ports to talk to the tomcat
host on. Tomcat doesn't decide it, Apache does.

> - all hosts, port 80: directory=/sites/defaultsite/. Here, the default site
> says something like "only ssl is allowed on this server. Please go to
> https://...."
> - www.site.com, port 443
> What will happen (in my tomcat setup) when you call www.site.com:80, is:
> - Apache uses the default vhost on port 80
> - Apache wants to return the default file "index.cfm"
> - Apache sends the request to Tomcat
> - tomcat recognizes the host name www.site.com in it's vhosts (meant for
> port 443 only, but  does not know it)
> - tomcat will execute the index.cfm of www.site.com, an return the output to
> apache
> - apache sends the wrong content back to the user :-(
> Does anyone know how I can prevent this from happening?

I *think* what you want to do is control this in Apache.

Usually when I have a https only site, I'll redirect any requests for
http to https. I use a rewrite most times, I think, but there's
several ways to do it that prevent any content from being served from
http.

Here's what I generally use inside the port 80 vhost (the @token@
stuff are cfdistro variable placeholders-- you'd replace them with the
real values):

<VirtualHost *:80>
ServerName @httpd.host.servername@
ErrorLog @httpd.log.dir@/@distro.name@-error_log
CustomLog @httpd.log.dir@/@distro.name@-access_log common
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*)$ https://@httpd.host.servername@/$1 [L,R]
Redirect "/" "https://@httpd.host.servername@/"
</VirtualHost>

You could modify it to only allow one page, like "please go to ssl
site here...", pretty easy.

Let me know if that's not what you meant. I'm not sure I understand
exactly what's going on.

Also, FWIW, here's what the command line for adding a vhost to tomcat
is using cfdistro:

./cfdistro.bat tomcat.configure -Dtomcat.dir=/path/to/tomcat
-Dtomcat.host=tomcat.host.name -Dwar.target.dir=/path/to/war

You could change the context path with -Dwar.contextpath=/something or
the ajp connector port with -Dtomcat.port.ajp=8109, etc..

Configuring apache is pretty similar.

All of cfdistro is pretty similar to that, actually. =]p

I know it's not automatic, but I don't really have to do it very
often, so it works pretty good for my use case. It can be automated
tho, especially since the cfantrunner tag will run cfdistro targets
from inside Railo... lol. =)

:Den

--
'Tis the sharpness of our mind that gives the edge to our pains and pleasures.
Michel de Montaigne

[Paul Klinkenberg]

Hi Den,

I indeed parse the whole httpd.conf + Includes, because the app might be run on webservers where cfexecute is disabled :-( Anyway, already finished the parsing script ;-)

To give you (and others) some more insight, this is an extract of my httpd.conf (based on this blog post by Sean):

----------------------------------------------------------

<IfModule !proxy_module>

LoadModule proxy_module libexec/apache2/mod_proxy.so

</IfModule>

<IfModule !rewrite_module>

LoadModule rewrite_module libexec/apache2/mod_rewrite.so

</IfModule>

ProxyPreserveHost On

ProxyPassReverse / ajp://localhost:8009/

RewriteEngine On

## All urls ending in .cfm/cfc, and urls containing '.cfm/' and '.cfc/', are passed to Tomcat-Railo:

RewriteRule ^/(.*\.cf[cm])$ ajp://localhost:8009/$1 [P,NC]

RewriteRule ^/(.*\.cf[cm])(/.*)$ ajp://localhost:8009/$1?path_info=$2 [P,NC,QSA]

## Redirect all flash/flex/amf calls to Tomcat-Railo:

RewriteRule ^/((flashservices/gateway|messagebroker/|flex2gateway/|openamf/gateway/).*) ajp://localhost:8009/$1 [P,NC]

<VirtualHost *:80>

DocumentRoot /developing/defaultSite/data/

RewriteEngine On

RewriteOptions Inherit

</VirtualHost>

<VirtualHost 127.0.0.1:443>

DocumentRoot /developing/floorplans/

    ServerName floorplans.local

RewriteEngine On

RewriteOptions Inherit

[... and some ssl config... ]

</VirtualHost>

------------------------------------------------------------------------

And this is a part of the tomcat server.xml:

------------------------------------------------------------------------

 <!-- Define an AJP 1.3 Connector on port 8009 -->

 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

 <Engine name="Catalina" defaultHost="localhost">

   <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

<Context path="" docBase="/developing/defaultSite/data" />

</Host>

<Host name="floorplans.local" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

<Context path="" docBase="/developing/floorplans" />

</Host>

</Engine>

------------------------------------------------------------------------

When I call http://floorplans.local:80/, Apache will use the first <Virtualhost> entry, but when it proxies the request to tomcat, tomcat will use the 2nd <Host>, because it does not look at the port.

I hope you now understand my question better :-)

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[Todd Rafferty]

btw, Jamie Krug has some stuff you may want to consider:
http://jamiekrug.com/blog/index.cfm/2010/8/31/cfml-tomcat-apache-ajp-proxy-redux

[denstar]

On Mon, Sep 13, 2010 at 11:47 AM, Paul Klinkenberg wrote:
> Hi Den,
> I indeed parse the whole httpd.conf + Includes, because the app might be run
> on webservers where cfexecute is disabled :-( Anyway, already finished the
> parsing script ;-)

You wrote a parser for httpd confs? And I thought *I* was crazy! ;-)

Hrm. What if cffile is disabled, or sandboxing type stuff is going
on, or the user running CFML isn't the user running the HTTP process
and doesn't have access (assuming this is run from some CFML code)?

What are the assumptions that you're working under, what level of
control are you targeting?

> To give you (and others) some more insight, this is an extract of my
> httpd.conf (based on this blog post by Sean):
> ----------------------------------------------------------

...

I like the ifModule directives. I should do that instead of a crappy
search for the LoadModule lines.

Since you're doing your proxying outside of the vhosts, you're kinda
screwed. Not really, but sorta.

You could use URLRewriteFilter on the Tomcat side and tell it to do
stuff based on the HTTPS-ness of the request... but you're asking for
trouble by using one global proxy IMO (vs doing the proxying in the
vhosts). I guess the point here isn't about doing stuff "right", but
doing it "easy", neh?

I wonder if that mod_actions deal for adding a "handler" might be
better... even so tho, I'm thinking having the user add a line or
three to the vhost isn't so bad. I think that's even how ACF does
it-- or at least did it, IIRC.

> ------------------------------------------------------------------------
> When I call http://floorplans.local:80/, Apache will use the first
> <Virtualhost> entry, but when it proxies the request to tomcat, tomcat will
> use the 2nd <Host>, because it does not look at the port.
> I hope you now understand my question better :-)

Yeah, I see what's going on 100%. I'd recommend you go ahead and bite
the bullet and move the configuration out of the main httpd conf and
into the vhosts themselves, but I know that goes against your goal of
not having to do anything special in vhosts to leverage CFML.

I just think, especially with SSL in the mix -- which has some quirks
(you can't share IPs, cookie hacks, etc.) -- you'll be asking for hurt
if you roll with an implementation like this. Somebody will ask you
"how to I run site 1 on one instance of tomcat and site 2 on another?"
and you'll be like, "very carefully!" =)p. There's other issues too
(how do I disable CFML handling for a specific site, etc.), but it's
up to you how much maintenance ease you're willing to trade for
initial installation ease.

Anyways, I think I'll roll with "use URLRewriteFilter", as the advice
to solve this specific problem. Watch that long tail tho, my friend!

:Den

--
Virtue rejects facility to be her companion. She requires a craggy,
rough and thorny way.
Michel de Montaigne

[Paul Klinkenberg]

Hi Todd,

Now THAT was an awesome tip! It beats the crap out of the config I already had.

Thanks a lot!!!

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[Paul Klinkenberg]

Hi Den,

Well, not really a parser... It just Includes all Includes, changes relative paths to abs paths, and then filters out the stuff I need. Will be posting it soon anyway.

Yeah, which requirements should I consider, that's a good one. In my 9.5 years experience, I have seen a lot of different server setups. The most common disablings is cfexecute, so I just wanted to circumvent that one.

"how to I run site 1 on one instance of tomcat and site 2 on another?"

If someone asks that question, but also wants a no-fuss installation, then I'd indeed say "very carefully" ;-)

It's besides the scope of this project.

With the tip that Todd gave, I will now try to find out if I can make a conditional "ProxyPassMatch" dependent on the cgi.server_port. If that is possible, then I guess I'm almost there...

To be continued...

Thanks for all the help btw!

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[denstar]

On Mon, Sep 13, 2010 at 2:43 PM, Paul Klinkenberg wrote:
> Hi Den,

> Well, not really a parser... It just Includes all Includes, changes relative
> paths to abs paths, and then filters out the stuff I need. Will be posting
> it soon anyway.
> Yeah, which requirements should I consider, that's a good one. In my 9.5
> years experience, I have seen a lot of different server setups. The most
> common disablings is cfexecute, so I just wanted to circumvent that one.
> "how to I run site 1 on one instance of tomcat and site 2 on another?"
> If someone asks that question, but also wants a no-fuss installation, then
> I'd indeed say "very carefully" ;-)
> It's besides the scope of this project.

Sounds good.

> With the tip that Todd gave, I will now try to find out if I can make a
> conditional "ProxyPassMatch" dependent on the cgi.server_port. If that is
> possible, then I guess I'm almost there...
> To be continued...
>
> Thanks for all the help btw!

No problemo! Unless I'm missing something, that configuration is
/basically/ the same as what you had.

I didn't even think about it, but it would be as easy to use a simple
rewrite condition inside apache, as it would be to use
URLRewriteFilter. Way easier, really, cuz you don't have to set
anything else up. =))

Here's one that should work with your old way of doing it (which takes
into account things like Flex and charting, BTW-- don't forget those,
like I have time and um, again).

Just stick the rewrite condition I mentioned earlier before any of
your proxy requests.

Ex:

RewriteCond %{SERVER_PORT} !^443$

RewriteRule ^/(.*\.cf[cm])$ ajp://localhost:8009/$1 [P,NC]

This says, if it's *not* a https request, pass it on to Tomcat.

Just another idea. Force be with you, man!

:Den

--
We can be knowledgable with other men's knowledge but we cannot be
wise with other men's wisdom.
Michel de Montaigne

[Paul Klinkenberg]

Hi Den,

To get the rewriterules which are outside the <Virtualhost> sections, to work _within_ a <virtualhost> block, I needed to add these 2 lines into every <Virtualhost>:

RewriteEngine On

RewriteOptions Inherit

With the new method, pointed out by Todd, I can leave the <Virtualhost> sections within apache alone. This way, I only need to add a bit of extra configuration once!

I am now going to look for a proxyPassCond or something :-)

Paul klinkenberg

------------
Dit bericht is verstuurd via mijn iPhone, en is daarom wellicht bondiger dan u van mij gewend bent.

Op 13 sep 2010 om 23:34 heeft denstar <vallia...@gmail.com> het volgende geschreven:\

[denstar]

On Tue, Sep 14, 2010 at 12:57 AM, Paul Klinkenberg wrote:
> Hi Den,
>

> To get the rewriterules which are outside the <Virtualhost> sections, to
> work _within_ a <virtualhost> block, I needed to add these 2 lines into
> every <Virtualhost>:
> RewriteEngine On
> RewriteOptions Inherit
> With the new method, pointed out by Todd, I can leave the <Virtualhost>
> sections within apache alone. This way, I only need to add a bit of extra
> configuration once!

Ahhh... I see.

> I am now going to look for a proxyPassCond or something :-)

Heh. You can match on the protocol part of the URL, so something like

<ProxyMatch "^http://.*">

Would do it for you, I think.

:Den

--
A nation may lose its liberties in a day and not miss them in a century.
Baron de Montesquieu

[Paul Klinkenberg]

Hi all,

I have been reading a lot (yes, a LOT) of tomcat documentation lately, and have been trying all kinds of tomcat confiruations. 

The goal was to get tomcat to pick up new virtual hosts wtihout the need of a restart, plus no necessary per-host settings in Apache configuration.

I have created a document on this subject, with an extract of my findings. I have added this as an attachment.

Botomline is: I haven't found a fool-proof option for a "no-fuss Railo configuration". Please read the doc to see why.

I am hoping on you guys to come up with an even better approach. Or just an idea or any hint to get me any further.

Current blockers can be read in the "Cons" sections of the document. If you have a solution for any of those, please share it.

[denstar]

On Wed, Sep 22, 2010 at 5:17 PM, Paul Klinkenberg wrote:
...

> I am hoping on you guys to come up with an even better approach. Or just an
> idea or any hint to get me any further.
> Current blockers can be read in the "Cons" sections of the document. If you
> have a solution for any of those, please share it.

Basically, I *think* this is the argument from the Tomcat camp:

They could have easily added a dynamic host deal, but have chosen not
to. The reasoning being, that multiple hosts shouldn't share tomcat
instances, as if one host has a problem, the entire server has a
problem.

I guess if you don't think of each context as an app, this makes
sense. It's more JEE-centric mentality, maybe-- the various
servlets/contexts on one host sorta comprise one application.
From a CFML perspective, each context is an app, generally. One bad
context (app) can bring down the server it's contained in. So if
you're going to have multiple contexts, might as well have multiple
hosts, is my thinking. Eh. *shrug*

Anyways, it looks like the options are to:

a) add the hosts to the server.xml file, and then leverage the
host-manager servlet to dynamically add them to an (if running)
running Tomcat instance (this is what cfdistro does now)-- to do this
though, you have to add some credentials to the tomcat-users.xml file,
and you want to wrap both operations in a script of some sort.

b) write a servlet that watches the server.xml file for changes, and
then runs the code that host-manager runs (similar to the code in that
link I posted). Hell, we could get fancy and make it work like Resin,
if we wanted, watching directories y todo. Tho Resin actually fires
up individual JVMs for each host (I think, using the watchdog), which
is a pretty big difference right there. :)

c) fire up a Tomcat instance per host. Use a script to set the port
numbers dynamically. (8000 instance might be a bit much. (But this
is theoretically what Resin is doing, I think, which is a little
boggling.))

Eh. Something along those lines.

:Den

--
I am not the born; how can there be either birth or death for me?
Guru Nanak

[Paul Klinkenberg]

Hi Denstar,

You are probably right, in using the tomcat hosts-manager. Reason I didn't look further into that one, is that I read a lot of complaints which said that hosts added with the host-manager, weren't persisted after a tomcat restart (could've been outdated info, I'm not sure). But I could off course both add the Host to server.xml, AND directly add it by using the host-manager! This will get me on my way again :-)

I will try to borrow the host-manager code from cfdistro then, if you don't mind.

Regarding Resin: it starts 2 (java) processes: one is the watchdog, the other the engine itself. I am running a lot of virtual hosts on Resin, but only these 2 exist. So one  virtual host could bring resin down as well, but with the great advantage that the watchdog process will then restart the engine, after which everything works again. Unless you get permgen memory problems btw; then you still have to reboot manually.

Thanks for the great tip!

If anybody else has some ideas, please share it!

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

[denstar]

On Thu, Sep 23, 2010 at 4:06 AM, Paul Klinkenberg wrote:
> Hi Denstar,
> You are probably right, in using the tomcat hosts-manager. Reason I didn't
> look further into that one, is that I read a lot of complaints which said
> that hosts added with the host-manager, weren't persisted after a tomcat
> restart (could've been outdated info, I'm not sure). But I could off course
> both add the Host to server.xml, AND directly add it by using the
> host-manager! This will get me on my way again :-)
> I will try to borrow the host-manager code from cfdistro then, if you don't
> mind.

Yup, I can confirm that the settings are still *not* persisted when using the host-manager servlet.  (Maybe version 7 changes this, haven't checked)

Apparently there is a secret function you can run from jconsole that will attempt to save the host to the server.xml file, but it's sorta buggy, so I said screw it, and just do it how you suggest-- myself.

You can take whatever the hell is useful to ya from cfdistro, and do whatever the hell you'd like with it. :)

Here's the relevant ant target for adding a host to tomcat:

    <target name="tomcat.host.add" description="add the host" depends="probe-manager">
        <property name="tomcat.deploy.dir.absolute" location="${tomcat.deploy.dir}" />
        <antcontrib:var name="tomcat.host.exists" unset="true"/>
        <xmltask source="${tomcat.dir}/conf/server.xml" dest="${tomcat.dir}/conf/server.xml">
            <replace path="Server/Service/Connector[@protocol='HTTP/1.1']/@port" withText="${tomcat.port.http}"/>
            <replace path="Server/Service/Connector[@protocol='AJP/1.3']/@port" withText="${tomcat.port.ajp}"/>
            <copy path="Server/Service/Engine/Host[@name='${tomcat.host}']/@name" attrValue="true" property="tomcat.host.exists"/>
            <replace path="Server/Service/Engine/Host[@name='${tomcat.host}']" if="tomcat.host.exists">
            <![CDATA[
    <Host appBase="${tomcat.deploy.dir.absolute}" autoDeploy="true" name="${tomcat.host}" unpackWARs="true" xmlNamespaceAware="false" xmlValidation="false" />
            ]]>
            </replace>
            <insert path="Server/Service/Engine" position="under" unless="tomcat.host.exists">
            <![CDATA[
    <Host appBase="${tomcat.deploy.dir.absolute}" autoDeploy="true" name="${tomcat.host}" unpackWARs="true" xmlNamespaceAware="false" xmlValidation="false" />
            ]]>
            </insert>
        </xmltask>
        <antcontrib:if>
            <isset property="tomcat.host-manager.running" />
            <then>
                <get src="${tomcat.host-manager.url}/add?name=${tomcat.host}&amp;aliases=${tomcat.host.aliases}&amp;appBase=${tomcat.deploy.dir.absolute}&amp;autoDeploy=on&amp;deployOnStartup=on&amp;deployXML=on&amp;unpackWARs=on" verbose="true" ignoreerrors="false" dest="host-results.txt" username="${tomcat.manager.username}" password="${tomcat.manager.password}"/>
                  <loadfile property="host-results" srcFile="host-results.txt"/>
                  <echo>${host-results}</echo>
            </then>
        </antcontrib:if>
    </target>

You can probably make out that it adds the stuff to the server.xml file, and then if it detects that the host-manager is available, passes it a request to add the host to the running instance.

I can vouch that this works freaking awesomely.  No restart required if Tomcat is already running!  You can stop and remove them on the fly as well!

> Regarding Resin: it starts 2 (java) processes: one is the watchdog, the
> other the engine itself. I am running a lot of virtual hosts on Resin, but
> only these 2 exist. So one  virtual host could bring resin down as well, but
> with the great advantage that the watchdog process will then restart the
> engine, after which everything works again. Unless you get permgen memory
> problems btw; then you still have to reboot manually.

Ah, ok, that makes more sense.  Thanks for the clarification!

:Den

--
Whatever kind of seed is sown in a field, prepared in due season, a plant of that same kind, marked with the peculiar qualities of the seed, springs up in it.
Guru Nanak

[Jamie Krug]

Wow, what a thread! I finally made it to the end here, so far ;-) A
number of questions have come up, and the question/confusion over
virtual hosting in both Apache and Tomcat (for example--i.e., both Web
server and application server) comes up *constantly* when I'm
discussing any of this type of stuff with CFML developers. I think the
primary source of confusion is the "magic" of the JRun connector,
which many people have come to expect. A bunch of folks have already
detailed this, so I won't restate it, but will reiterate that there
are pros and cons.

The bottom line, in my mind is this: adding virtual hosts (or just
using unique contexts) in a Java application server (e.g., Tomcat) may
be an adjustment or a tiny bit of overhead, but it just opens so many
doors and provides incredible flexibility!

I'm curious whether folks here have these concerns for the sake of a
development environment, a production environment, or both. If it's a
development environment, if you step back and think about it, you
might see that non-root contexts and/or separate Tomcat instances are
perfectly acceptable, if not preferable. Keep in mind that Apache and
IIS are often completely unnecessary, especially in development. Sure,
there may be some apps that are tied to URL rewriting or something,
but I find, more often than not, that localhost:8080 or localhost:8080/
context is all I need to test and code my CFML apps!

In development, at least 9 times out of 10, for each project/app I'm
just firing up a new Tomcat instance with a single Railo WAR deployed.
I skip any Apache involvement, and I don't even add an /etc/hosts
entry, because I can just hit localhost:8080. I usually don't bother
changing the port either, because I'm just developing one app at a
time, and therefore only need one Tomcat instance running.

Tomcat provides some nice tooling to allow multiple instances to share
the same core library (i.e., needing only a skeleton directory
structure, server.xml and a couple environment variables set/passed to
startup script to identify path). Ubuntu has jumped on this capability
and makes it insanely simple/fast/clean/lightweight to fire up new
Tomcat instances in a single command (check out "Using private
instances" section at https://help.ubuntu.com/10.04/serverguide/C/tomcat.html).

Here's an example, from a command line (though all but one command
could really be done in GUI if you prefer), of setting up a complete
project directory with Tomcat instance and Railo WAR:

tomcat6-instance-create newproject
cp ~/Downloads/railo-3.1.2.001.war newproject/webapps/ROOT.war
./newproject/bin/startup.sh

With those 3 quick commands, I have Tomcat running with Railo deployed
with root context at http://localhost:8080/.

In reality, I do have a few directory organization/style preferences
and shortcuts that I use, but I'll blog those details soon--just
wanted to show how quick this can happen. So, yes, I have
*configuration* for a LOT of Tomcat instances on my laptop, but this
is really only a directory skeleton with a server.xml and a couple one
or two liner start/stop scripts that call a main start/stop script. I
could have a hundred Tomcat instances at the ready in this style and
we're only talking about as much disk space as is used by 100
server.xml files and 200 start/stop scripts that contain only two
lines of text each. Well, plus the Railo WAR under each of course.

I really like developing with this setup, as I don't have to worry
about trying to cram completely different projects into the same
version of Railo/OpenBD/ACF (e.g., some need to be tested on stable,
others I like running on BER, some client-specific, etc.).

On the other hand, if you have a handful of apps that are related and
should be running under the same Tomcat instance, you might want to
install Railo on the common class loader style, so you really only
have one core Railo library and multiple Web contexts running off
that. If this is the case, I'd say just manage Host entries in
server.xml. If the time to restart is an issue, than maybe you don't
want to risk running these multiple CFML apps under the same instance
in the first place--use separate Tomcat instances (just use different
ports if running simultaneously).

I know this doesn't fit every situation, but I wanted to throw it out
here. It works great for me. I do have some sites that are tied to URL
rewriting, in which case I just setup an Apache virtual host as well.
Just keep in mind that Tomcat may already do everything you need for
developing a given CFML app :D

The options are seemingly endless, and I know there's probably 20
other points that came to mind while reading this long, thoughtful
discussion, but I've rambled enough for now. Thanks for anyone reading
along--hope it helps in some way!

Cheers,
Jamie

> src="${tomcat.host-manager.url}/add?name=${tomcat.host}&amp;aliases=${tomca t.host.aliases}&amp;appBase=${tomcat.deploy.dir.absolute}&amp;autoDeploy=on &amp;deployOnStartup=on&amp;deployXML=on&amp;unpackWARs=on"