The built-in web server in ColdFusion 10: enabling it, configuring it, reconsidering it
Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.You may have noticed during installation of CF 10 (as with previous releases) that you are offered the option to either connect CF to an external web server if you have one installed (such as Apache or IIS), or you can use an offered "built-in web server" (or what is also sometimes referred to as the internal web server).
That's not really new news, as the same option was offered in CF 6-9. But there are some new things in CF10 to consider about that option, and that's what I'd like to share here.
First, I want to show how if you chose NOT to enable the built-in web server, you CAN enable it after the fact, with just a simple modification to a single xml file (which is a different one in CF10, and I want to show where that is, share some tips on changing it, and point out where to learn more.)
But there are also still more things about the built-in web server that you can control, which you may not readily discern even from the docs, and I provide here additional info with respect to that.
Finally, while in previous releases the built-in web server (which was really the JRun web server) was something generally regarded (even warned in the installer) to be used only for development and testing, the built-in web server in ColdFusion 10 is in fact the Tomcat web server (Coyote), which is a much better web server out of the box, so you may want to consider it even for production.
I realize that last point will be "pushing it" for some. :-) Hey, I'm not saying that you should change anything, just letting you know that some might reconsider things. Hear me out, please. I'm just sharing documented info that might not be so readily found about a relatively new subject for the CF community (so don't shoot the messenger!) I'll point later to other Tomcat references making the same point, such as this 2010 article (no longer available via its original link, http://www.tomcatexpert.com/blog/2010/03/24/myth-or-truth-one-should-always-use-apache-httpd-front-apache-tomcat-improve-perform, but archived here: Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?.
Background
As in previous releases, since CF6, during installation, you're asked if you want to connect CF to an external web server (IIS, Apache, etc.) or to use its internal web server (such as to avoid conflict with another release of CF running on the same machine that may already be connected to the external web server.) It's a helpful option, especially for testing.
It can also be helpful, even after you install, if you may want to see how something works with it (the internal web server) as compared to running a request via your external web server. And again, you may even want to consider using it for production. More on that later.
Enabling/disabling the built-in web server in CF10
So first, if perhaps you didn't enable the built-in web server during installation, and you want to consider it now (for whatever reason), how do you enable it after the fact? (Or how would you disable it, if you had enabled it and now don't want to?)
Again, it's just a matter of editing an XML file, but it's not the jrun.xml file that it was in CF 6-9, since CF10 now runs instead atop Apache Tomcat. And it is, in fact, the Tomcat web server (not to be confused with the Apache web server) that you are enabling with you enable CF's "built-in web server".
You want to edit the cfroot\cfusion\runtime\conf\server.xml file. In there, you should find an XML entry surrounded by the comment referring to "internal webserver". Here's an example:
-->
- <!-- internal webserver start
-->
<Connector executor="tomcatThreadPool" maxThreads="50"
port="8500" protocol="org.apache.coyote.http11.Http11Protocol"
connectionTimeout="20000"
redirectPort="8445" />
To be clear, you do NOT want to stop at or edit (if you find it) a COMMENTED line which might look very similar to the "Connector" line above but which refers instead to protocol="org.apache.coyote.http11.Http11NioProtocol". That's not what you want to edit. Keep looking for for the external web server instead. More on this alternative protocol later.)
(If you search for "internal webserver" and don't find it, it may just be that you don't have that particular comment in your server.xml file. Search instead for "Http11Protocol" (without the quotes). If there's not even a line referring to that, then it means that the XML for this built-in web server feature has not been implemented at all for your instance, even as a comment. I'll show you how to add it in a moment.)
If the connector entry shown above (the one surrounded by the "internal webserver" comment) is commented out, that means the internal web server is currently disabled. if you want to enable it, just remove the comments (and save the file and restart CF, more in a moment).
If it is there but not commented out, and you want to disable the built-in web server, then add comments surrounding it, save the file and restart CF. (Use XML/HTML comments, not CFML comments--2 dashes, not 3!)
If the line is not there at all (which may be so in the initial cfusion instance, if you didn't enable the feature it at installation of CF10 or 11), you can add just it yourself. Use the same lines I offer above (assuming you don't have another instance already using port 8500, in which case you should change this code to an unused port, like 8501). You can just add the lines between the Executor line and the other uncommented Connector line you'll find (referring to protocol="AJP/1.3", for the external web server.)
Again, do be very careful when working in these (and indeed any) XML files. If you get the comments wrong, or leave otherwise some malformed entries (like a missing slash or duplicated attribute), the file won't be able to be parsed. You may find that CF either won't start at all! Or worse, it may start (the service) but not be able to process any CFML requests. (In that case, the coldfusion-error.log or coldfusion-out.log may show you that it couldn't parse this file.)
And again, after making the desired change and saving the file, restart CF to cause the new setting to take effect.
The port used for the built-in web server
You can test things by visiting your site at the port indicated by the PORT attribute in that xml configuration line (8500, above). If that port is already taken when CF tries to start, then again CF will not start and you'll need to specify a different port in the file, then save it and restart CF.)
You can in fact find the info above (enabling/disabling the built-in web server, configuring its port) documented in the CF 10 docset, specifically "Installing Adobe ColdFusion 10", and particularly starting at its page 8 on "Using the built-in web server".
(One minor gotcha in the docs, related to something I already mentioned: in the current CF10 docs, on that page I link to just above, the value shown for the PROTOCOL attribute of the CONNECTOR element is instead a value of org.apache.coyote.http11.Http11NioProtocol. But the value as deployed in CF10 by default is rather the org.apache.coyote.http11.Http11Protocol that I showed. Just pointing this out if one did "search" their server.xml for that whole string above. Also, of course, your PORT could differ. As I said above, just search the file for "internal webserver" which appears in a comment above it.)
Still more options to configure the built-in web server
But there's still more you can do to configure the built-in web server, and that's another main reason I'm writing here.
Did you know you could change the default document root, add virtual directories (aliases or mappings, to point to directories outside of the default docroot), controlling directory browsing, and set custom error pages, all with respect to requests made using the internal web server? You can, indeed.
(And FWIW, you could do such things with the JRun web server, too, if you knew how and where to set these things, such as I discussed some in a blog entry from 2002.)
Anyway, for more on these configurable settings for the internal web server, though they are not documented in the CF manuals, they are documented in in an article by Adobe engineer Kavya Maiya, called Working with Tomcat as the built-in application server. After a couple of introductory sections that are not specifically about the built-in web server, she does share these other tips on configuring it starting at this section.
There's still more you may want to consider tweaking about the built-in web server, but I'll share more on that in just a moment.
Still more on running CF on Tomcat (even without using its built-in web server)
And I'll note that both those resources do discuss some other things about running "CF on Tomcat" (as CF10 does) beyond just using its built-in web server. It's worth considering, because in fact while the Adobe team has tried where feasible to keep CF10 working just like previous releases, there are in fact differences about CF10 with respect to how it runs on Tomcat.
That has nothing to do with the choice of internal or external web server. And some may know that I did an even more extended discussion on this topic in a talk I've given at several recent conferences, "What's New and Different About CF 10 on Tomcat", and you can find the presentation slides and recording here.
Again, the bulk of that talk is NOT about running CF with Tomcat's internal web server, but rather is about just the overall implications (and features and differences) related to the fact that CF runs atop Tomcat now, rather than JRun. There are a lot of interesting and compelling differences. I plan to eventually start blogging about those as well, as some may never otherwise see the info if it's locked up only in the preso. :-)
A couple of final comments about built-in/internal/Tomcat web server
Before ending this entry, I want to make a couple more points that you won't hear too many others discussing for now.
The internal/Tomcat web server: it's not just for testing any more
I hinted at this in the opening, and I want to clarify. Typically, we have long been told to regard CF's internal web server as "just for development and testing, not for production". That made sense with respect to the old (really old) JRun web server that was within CF 6-9. But again, the CF10 internal web server is the Tomcat (Coyote) web server, and while historically it, too, was regarded as "for development or light use only", the Apache/Coyote team have continuously updated it (a big difference from JRun, which stopped development years ago), and many do indeed use that Coyote web server in production.
(Of course, if you DO choose to use an external web server instead, there's nothing wrong with it at all. I'm not asserting folks should stop, or that there are not indeed cases where it DOES make sense to use an external web server. This is just to say that with Tomcat, as compared to JRun, the internal web server is something you could consider for production use.)
And of course, "production" means different things to different people. Some have a site getting thousands of hits per day, others get millions.
Still, there are folks in the Tomcat community who have shared their observations to THAT community suggesting people think twice before presuming you'd always want/need to put an external web server in front of Tomcat. Here are some references to consider.
(Where they refer to "Apache httpd", they mean simply the Apache web server, since Tomcat is formally "Apache Tomcat". And for those who would use IIS, it's reasonable to assume that most of the conclusions in these articles would apply to a comparison with it as well.)
Besides the "myths" article shared above, see also:
- "Some notes on tomcat connector performance", especially his conclusion, "Apache Tomcat performs on a level comparable to Apache HTTPD. This is at least the case for dynamic requests, but I have seen similar results for static requests."
Of course, folks should always test things for themselves before making any conclusive decisions.
And I won't deny (as surely some would want to point out) that the reason they prefer an "external web server" is that those web servers often have far greater configurability, or greater security controls, or better support for things like url rewrites, or greater integration with other tools, and so on.
Again, I get all that. I've said it above, and I'll say it again: if you are happy using an external web server, I'm trying to persuade you to change. I'm simply saying that the former conclusion that "we would always want to" just isn't quite as valid as before. If that may help someone, that's the only reason I'm pointing all this out. :-)
For more on the Tomcat/Coyote web server
Finally, for more on the Tomcat/Coyote web server in general, which is known inside the Tomcat docs as the "http connector", including some more "configurable knobs" and choices that you may want to consider, see the Tomcat docs page on it. (By contrast, the "connector" for connecting Tomcat to an external web server is the ajp connector.)
Speaking of alternatives (just within the internal/Tomcat/Coyote web server/connector), I'll note that there is an available choice between "protocols", from the default "bio" to the "nio" protocol, as referred to briefly a couple of times above. CF uses the bio protocol by default. I'm not prepared myself to make any recommendation or indeed further comment on choosing among them.
Same with the many configurable options you'll find listed there. I'm sure some could prove to be very important. I just haven't enough time/experience with them yet to comment upon them.
But I'm sure some intrepid souls will be tempted to explore them, and tweak things, especially if they may be considering using that internal web server for production. Feel free to share what you learn here.
For now, I am satisfied to leave the protocol and all its settings at the default, as I am not yet myself using this internal web server for production.
One last warning about all this: beware that whenever you change settings that CF relies upon, you not only should test them thoroughly but also be sure to always mention the specific non-standard changes you've made when you're seeking help, whether from Adobe or the community. I see this sort of "unstated tweaking" lead to a lot of confusion and challenge when people are trying to help each other on the inter-tubes. Forewarned is forearmed. :-)
I have one more comment to make that is somewhat related to all the above (with respect to the internal "wwwroot" in CF, and how it's now used in CF10 regardless of whether you use the internal web server or not. But since it applies even for those who do not, and they may not be tempted to read this entry, given its title, I'll post that as a separate one soon.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
But I don't mean to suggest your question is not important. Indeed, I have addressed it in a previous entry, where you may find answers or insights to help, or there you could ask follow-up questions:
CF911: Lies, Damned Lies, and CF Request Timeouts...What You May Not Realize
http://www.carehart....
But do be sure to read the whole thing, and subsequent comments, before you would ask any follow-ups, please.
Hope that helps.
Thank YOU, @Lisa, and really glad it helped.
Cold Fusion resources such as this are becoming scarce. Keep up the good work. I love tuning servers and your article really helps in understanding how to better fine tune CF.
I have used nginx + railo 4 ( win 64bit ), I was really impressed by performance.
But I also want to try to use CF10 and what is best installation scenario will be? Built-In or something different?
Thanks
As to your question, there is no definitive answer. Each installation scenario will be different. Some prefer Apache, some IIS, some nginx. And some may even want to consider the built-in web server in CF10.
Again, the point of my blog entry was simply to discuss that built-in web server in CF10. As I hope I conveyed, while it's not something that most will consider as their main production web server fronting CF10, i just wanted to note (besides all the other info on using it) that some Tomcat folks would assert that it is production-ready. I wasn't making any additional warranty of "fitness for a particular use". :-)
And to your question, there's no one right answer to it, I would assert. You simply need to test and explore things for yourself.
I start playing with buil-in server and nginx on front to handle static files such as css, js etc..... and it slow on CF side, not sure why, completely different compare with Railo. Probably need to play with tomcat/jvm settings ..... but correct me if I'm wrong, regardless how to install built-on or with IIS at the end the same tomcat server version will handle CFM, it just provide a connector for selected front web server like IIS?
And as to your observation that performance is slow using that built-in web server, let me just caution you that there's no reason it should be inherently so. many run it find and see no such degradation.
But I will note that I have seen at least a couple of instances where it was so, and it turned out to be some sort of issue that was fixed by tweaking a timeout (to lower it, so it doesn't wait so long). If you want to test it, it's the C:\ColdFusion10\cfusion\runtime\conf\server.xml file, and its Connector executor="tomcatThreadPool" xml element, and its attribute keepAliveTimeout.
When I saw that problem, I found that adding that attribute and lowering its value to like 5000 at least kept it from waiting for its default of 60000, or 60 secs (not that it has that as its default, but it defaults to the value of the connectiontimeout attribute, and if it's not specified--and neither of them are in CF10 by default--which itself defaults to 60000).
@Roger, as we are talking here about the Tomcat web server as implemented within ColdFusion (which is deployed atop Tomcat, the application server), I think the answer is no.
First, there have not yet been any CF10 updates that implemented a new version of the Tomcat web server (or even a new version of Tomcat in general, as it lies underneath CF).
Second, you are not free to modify Tomcat (the application server) as it underlies CF, because Adobe has in fact themselves modified it to work with CF. And while I don't know for sure if Adobe modified Tomcat (the web server) as it underlies CF, And I suppose it might be possible for you to try to update it, I suspect it would not be supported.
Anyway, you have asked a question that really requires Adobe to answer. I'm just offering an answer from my perspective. I don't know that you can expect that they will necessarily offer an answer here, so you may want to find a way to ask them, such as on the Adobe CF forums. If you get an answer, feel free to share it here.
Itis my understanding that Adobe CF plans to release any Tomcat updates via the CF updaters.
That’s all good, but how do I upgrade the in-built Tomcat, in case Tomcat comes out with a critical fix or a security fix?
Well, ColdFusion 10 now has an amazing delivery mechanism with hotfix notification and installer. We will use the same infrastructure to keep the Tomcat engine updated. CF-Tomcat update should be available soon after Tomcat comes out with any critical fix. We will also make the same available for you to download and use.
http://blogs.coldfus...
I believe there are only a few items that are different with using standard Tomcat. One is SES, which is an easy workaround.
I also remember hearing about some patch to make standard Tomcat equivalent to CF Tomcat, however I have not heard anything about that in some time.
I have another question: Can i use the coldfusion cluster feature with the built-in tomcat? How?
I think an issue (in exploring that) may just be more that for the 12+ years of life of CF on JRun (CF6-9), no one would ever have considered using the built-in (jrun) web server for production purposes, let alone for a cluster of prod CF instances. As I'm noting in this entry, it could be that the tomcat web server (which now serves as CF10's built-in web server) is more capable to be considered at all for production.
So you may find no one talking about using it for clustering (let alone for production), so you may even have some people swear it will be impossible (but without even knowing for sure, just parroting the long-held assertion that the "built in web server" is not up to production use.)
Again, as I've been saying in the entry above (and in reply to comments), I'm not necessarily declaring that it is, just that it might be, because the Tomcat folks say it is, so it's worth people exploring.
And as with your question, it may be that it can or cannot be used with clustering, or it may be that it could but it doesn't work well because of some presumption in the configuration of CF cluster support that it would have only ever been used with an external web server (like IIS or Apache).
We'll see if anyone else has more thoughts.
Do you know any resource for information deploying CF10 on a pre-existing tomcat instance? I'd like to deploy native CF portlets on Liferay. Liferay is all ready stood up on Tomcat. Thoughts?
First, you CAN definitely install CF10 in any Java app server, at least with the Enterprise (or Trial or Developer) edition of CF. You would use the option offered during installation to use JEE EAR or WAR deployment (rather than the typical Server form of deployment), and the result of that would be an EAR or WAR file that you can then deploy in any JEE server or servlet engine, including Tomcat.
This is covered in the Installation manual (yes, there is more to the CF docs than just the CFML Reference), and it's not new (or different) in CF 10. If you need more direct assistance, I could help per my consulting services. More on the consulting page at carehart.org.
That said, this approach may not work for you, because you say you want to deploy CF Portlets into LifeRay which is already stood up on Tomcat. Well, that would mean that LifeRay is already deployed as its own ear or jar, whether you did it or it was done by a LifeRay installer.
But what I describe above would create a NEW ear or war, separate from LifeRay. I suspect you are asking how you may get CF portlets (running already in some other form of deployment) to run inside liferay. That will likely NOT be possible. You can't put one war or ear inside another. And you can't take just some functionality of CF and migrate it (alone) into another WAR. It's an all or nothing proposition.
So I suspect you may be hard pressed here. FWIW, you could have your liferay portlets get their content from CFCs or CFMs running in CF. That's not what you seek, of course, but that's really what portlets are about: getting functionality from somewhere within an app in a portlet, wherever that content may exist. That's the extensible nature of portets. I just don't think you'll be able to literally put "cf's portlets" into Liferay itself. That's not the extensibility intended in portlets, as I understand them at least.
But again, since this is not new for CF10 (both portlets and ear/war deployment), you may want to google for discussions that may have happened over the past several years with respect integrating CF and Liferay. I know where were discussions and blog entries about it in past years.
Hope that helps.
I've used it to route calls based on urls and it works just fine. Check out.
https://drive.google...
I am not sure that solves all your issues but it will allow you to make CF calls in your Liferay war.
Thanks! I was hoping to not have to set up Apache as the Liferay instance is part of a complex multi-node environment integrated with an ERP and other stuff, Ellucian's Luminis 5.1 portal. It uses Liferay as the portal platform. We have alot of CF functionality currently iframed in but want to move to native CF portlets for the same functionality. The deployed cfusion.war doesn't have a runtime or wsconfig directories. I cant find any tomcat connectors.
http://www.edu1world...
If Liferay is on tomcat is is most likely using mod_jk already so you woul dnot be adding any modules just definitions and mappings. http://tomcat.apache...
Good luck.
As for why you find no wsconfig in the CF WAR, I would guess it's that you have not yet run the CF web server connector tool to connect your external web server (Apache or IIS) to CF. That said, CF has its own built-in web server, the Tomcat web server. That may suit your needs, but I think your problems are far bigger than matters related to web server processing.
I think you will be greatly challenged to eitehr do or find info what what you are trying to do, as deploying CF into an existing WAR is NOT something that Adobe ever supported. Many have tried to shoehorn such a solution in, since CF 6 first was deployed on Java.
Again, I'll say that you may want to explore google for broader discussions of integrating CF and liferay. You may find either that someone HAS talked about how to get this merging of WARs to work, or instead they may talk about how to more effectively integrate CF and liferay WITHOUT doing such merging.
I seem to recall Rey Bango doing work with this about 5-6 years ago. Hope that helps.
Thanks again for the input. I dont know if I was clear before, cfusion and Liferay(Luminis) both sit in the same webapps directory in tomcat. when I attempt to use the URL https://my.liferay.i..., my browser gets prompted to download the index.cfm. It "finds" the file, tomcat just doesn't know what to do with it. This leads me to believe that somehow coldfusion servlets are not being "mapped" correctly.
The end result is that I'd like to use ColdFusion10 portlets (or portletized functionality) running natively in Liferay. I've scoured both product's forums and support fervently for a week trying to find a solution.
I really think the answer is in the web.xml files.
But you say that CF and LifeRay "both sit in the same webapps dir in tomcat". That does not make them a single webapp, of course. And if your url pointing to the liferay web app is trying to call a cfm page, like the admin, it won't work. CF is NOT in that liferay web app. They are separate.
As I said before, you cannot somehow merge them. It's virtually impossible, as they are entirely different web apps with all kinds of internal dependencies which would step on each other.
I say "virtually impossible", because I recall others trying to shoehorn it to make it work back in the day. You may find that (can't tell if that's what you've beeen looking for).
But I'll also say again that the issue may be that you're doing it wrong: maybe the way to have Liferay call CF portlets is not as if they are in the same app, but instead as if they are web services, for instance. CF certainly supports that (CFCs responding to web service calls), and I think LifeRay supports calling web services for portlet content. That's then not about using portlets "in CF" but calling CF content as a portlet in LifeRay. Hope that helps.
Again, though, this is WAY far afield of the point of this blog entry and I think if you continue to struggle you ought to open a thread in one of the many Adobe CF forums. but if you do find an answer and want to offer it here, some readers may (and I would) welcome seeing it.
Again, it IS simply the Tomcat web server that is provided within CF (as its "internal web server" in CF10, compared to the old "internal web server" for CF 6-9 which was the JRun web server.) And for any reading this comment but not yet having read the blog entry above, note that we are NOT talking here about use of CF10 with IIS or Apache.
So to your challenge, Francisco, you will find many resources on the web, from Apache docs and others, talking about how to configure Tomcat for virtual hosts.
While the most likely page you'll find is this, http://tomcat.apache..., a challenge is that you then have to translate what they say into something that makes sense in the context of how Adobe has packaged the Tomcat XML files. But it's not generally difficult if you persist in reading the docs and comparing the files.
But a perhaps better option is this article, http://oreilly.com/j..., which is from Jason Brittain, author of the classic Tomcat: The Definitive Guide. While that book and this article are dated, the article does have a specific section, "4. Configuring Virtual Hosts", which highlights how the key really is in the HOST element, and simply creating another. As it mentions, the element is in the server.xml file, and CF10 has one also. It's in C:\ColdFusion10\cfusion\runtime\conf\server.xml (or if you have other instances, it's in a subfolder of the ColdFusion10 directory that has the name of the instance).
And just as that page shows the host element to have nested subelements, so too does the one in CF's default server.xml file, so be careful in editing things. Note also that in CF's version, some of those nested elements have hard-coded references to the default hostname (localhost), and you may want to change those to use the name of whatever you call the new hostname. See also the comments that are offered in the file.
You may have to fiddle with it a few times to get it right. And you may find that CF doesn't start or doesn't work right if you get something wrong, so I would recommend you open the file with a good editor that allows you to do multiple undo's (Windows Notepad does not).
Finally, as for testing things, note that Brittain's article talks about how you would want to use a hosts file to test this (if you don't have real DNS settings to give names for your virtual hosts). This isn't the place for me to elaborate on that. But I do find another article covering the concept of Tomcat hosts that does show more on that, and gently introduces the whole notion of Tomcat virtual hosts:
http://www.ramkitech...
There may be still some more tips and traps. I'm afraid I'm just about to get on calls for much of the day, so can't do a test of the above to share any other tips, but I wanted to get this out while I had a moment.
I see there are still more articles sharing more tips that could help if you or others get stumped. Just search for: tomcat virtual host
Let me know how it goes for you.
<Engine name="Catalina" defaultHost="localhost">
. . .
<Host name="dev.in.francisco.org" appBase="webapps">
<Context path="/" docBase="/var/www/cfmx/wwwroot/dev.in.francisco.org" />
</Host>
. . .
</Engine>
I restart coldfusion and run the page. It does end up loading the page, but none of the coldfusion code gets evaluated/parsed. All I have is an index page with a cfoutput of the current date/time -- this was a simple test to get things going.
So this is where I'm stuck trying to figure out how to make this work with the custom "coldfusion tomcat" web server.
I was hoping someone had already had the experience using this internal web server and setting up virtual hosts within it that could shed some light. My next step was to start looking at the "apache" tomcat documentation, but was only a little concerned since you had mentioned that this ("coldfusion" tomcat) was a modified version of the official "apache" one.
Funny thing is, I'm doing all this b/c I can't use Apache web server with CF10 on my machine. I'm sure you've gathered it's a linux, specifically Linux MInt (based on Ubuntu 13.10), which uses apache 2.4, which isn't supported by ColdFusion's connectors and unfortunately, due to the OS version I can't downgrade apache to version 2.2.22. When I read your blog posts and saw your presentations I was hopeful that I could just use the internal web server and call it a day, but getting these virtual hosts working has really made that quite arduous.
If you are seeing your coldfusion templates being served as text, this is most likely what's missing.
Second, @Francisco, I'm so sorry that somehow I missed your comment from April. Did you resolve things? Or might Mike's suggestion help you? Any update is welcomed.
Finally, as for your concern about whether to look to the Tomcat docs for help because 'this ("coldfusion" tomcat) was a modified version of the official "apache" one' (as you recalled my pointing out), I'd say you'd nearly always still benefit by looking into those tomcat docs for things when you're doing something like this which is not documented much (if at all) by adobe.
Of course, by now your need for support of Apache 2.4 (which was missing in CF10 and drove you to look to the internal server) is solved now by update 14 that came out last month. If you missed it, see http://www.carehart....
Hope that helps.
We have an environment where we run both ColdFusion and tomcat separately. Can we serve our tomcat applications out of the ColdFusion built-in web server, or is that web-server custom built to serve only ColdFusion? The cfusion/runtime directory has a webapps directory - can I deploy a tomcat webapp there?
@Mike thanks for the additional info, I realized as much after my experience with CF10 and CF11.
On checking the server.xml file, the 'internal webserver' connector was commented out, even though I had specified the built in webserver during the cf installation. However, uncommenting this and restarting cf11 made no difference. I tried renaming the web.xml file in the WEB-INF folder under the webroot, and the pages behaved exactly the same - suggesting that this file is being ignored.
I then tried uncommenting the <Context /> statement in the server.xml file
<Context path="/" docBase="C:\ColdFusion11\cfusion\wwwroot" WorkDir="C:\ColdFusion11\cfusion\runtime\conf\Catalina\localhost\tmp" ></Context>
and this made no diffence either.
It appears that something is not configured correctly, but I'm running out of ideas. Any help on this would be appreciated.
As for you refernce to the server.xml and its internal web server config that you say is commented out, are you referring to the like like Connector port="8501" protocol="HTTP/1.1" ?
Also, when you test your URL, are you using whatever port is shown? And you've not changed it to 80, have you? If so, it's possible that some other web server is already running on the server, listening on port 80, and THAT's why you are not having success.
As for the web.xml tweaks you were trying, including renaming the file, you don't indicate if you restarted CF between such steps. You must, for them to take effect.
In fact, even if you were using an external web server (like IIS or Apache, whether intentionally or unexpectedly as I propose above), the web.xml (in wwwroot\WEB-INF) is used by CF regardless. It's NOT used only for requests made using the internal web server (the tomcat web server). I just renamed it and restarted CF, and made a request, and I got a prompt to save the CF file I was requesting, whether I was requesting it using the internal or external web server.
Let me know if any of that helps.
I don't have another webserver running. I do have an index.cfm, and an index.htm file in the web root folder. I was using the correct, 8500 port in the url, and I was restarting cf after making every change. Since then, I've uninstalled cf11, turned off my firewall, and done a repeat install, but still get the same result.
ie. browse to http://127.0.0.1:850..., and I get a directory list that includes both my index.cfm and index.htm. However, if I double click on either, the appropriate web page opens up. ColdFusion is running because I can display the current date on the index.cfm page.
The installation process didn't leave much room for getting anything wrong, especially when installing the developer edition, with the Developer Profile, and selecting the Built-in webserver. On completing the installation and server configuration, I opened cfadmin and installed the latest update (5). All of that worked perfectly.
The web.xml file in the WEB-INF folder does contain both index.cfm and index.htm in the welcome-file-list. I would expect that this would allow me to just navigate to the web folder and the index.cfm file would open since it is the first in the welcome-file-list. But it doesn't.
The server.xml file has the following connector commented out:
<Connector executor="tomcatThreadPool"
port="8500" protocol="HTTP/1.1"
connectionTimeout="2000"
redirectPort="8447" />
It is interesting that the redirectPort is 8447 and not 8445, which is also true for the <Connector port="8500" .... /> just above it, and which is not commented out. I don't know if that is significant or not.
I hope that makes the problem clearer. I'm wondering if it might be some obscure permissions problem, or something to do with using 64bit windows 7.
The problem was case sensitivity, which was also causing about half of the images in my existing application to not display. Fixing the images also fixed the default web pages.
I found the solution at https://forums.adobe...
It involves changing the line in the context.xml file in cfusion\runtime\conf from
<Context>
to
<Context AllowLinking="true" caseSensitive="true">
This problem apparently only exists on the Tomcat webserver, which is designed to be case sensitive by default. It doesn't exist on Apache or IIS.
Unfortunately, there is also a serious security problem with applying this fix - read all of the adobe forum comments. So, this is also a very good reason why you should not use Tomcat for a production webserver. It should be ok for development.
Finally, I have to have an Adobe gripe. This is a serious issue that was raised 3 years ago. Adobe accepted it as a bug to be fixed at that time. It still isn't fixed, and they're still using Tomcat for their built-in development webserver. They have not documented any of this. It's potentially a security issue, and it's just cost me two days of dev time.
I've used cf since version 1.5. It's an awesome development environment. But the quality of their installation and configuration tools, and associated documentation, sucks.
I see that forum post saying though this is NOT an issue so much with the filename portion of cfm files but more with other files (though it does seem the extension portion of cfm files is case sensitive). Is that what you found?
Were things not working when you referred only to a folder name because you had a mixed-case name for your index.htm, perhaps, like naming it Index.htm (capital i)? Just want to understand what you found, since this will stand over time for others.
Can't help with the Adobe gripe really, though I'd agree that (if that security issue were resolved or better explained) it could perhaps make sense on Windows for that setting to be enabled by default.
Of course, folks on Linux have been dealing with case sensitivity forever, including cfm file names, such as having to remember also to name Application.cfc/cfm with a capital a for that reason.
But you can certainly add a vote or comment to those bug reports, or file another (since they say it's fixed and you would note how it's not).
(To any who may think that filing bugs is pointless, note that CF11 update 5 yesterday had over 100 bug fixes, and update 3 had almost 200.)
Finally, as for the production-worthiness of the internal web server, I'll agree that this issue could be a stumbling block, but with the fix I don't think it's a show-stopper itself (again, more needs to be understood about the asserted security problem. Also, that's from 2012. Things could have changed. Indeed, update 3 of CF11 and update 14 of CF10 both included updates to Tomcat 7.0.54, so someone may want to dig into whether that or any preceding updates it included may have changed that security concern. It's always possible).
Anyway, where I do mention above the possibility of using the Tomcat web server for production, I do hedge things and say there's no reason to stop using an external web server. And I point out comments from others in the Tomcat community asserting how it (the tomcat web server) can be used for production workloads, so it's not an outlandish idea (as it would have been for the JRun web server).
But it was certainly not the primary goal of the post to propose that. It was just one thing among many that I wanted to share about the "new" internal web server, when it came out with CF10 (and seems will be with us for a few releases) in the hopes the info may help others.
In any case, glad it served as a place for you to discuss your problem and solution.
If you're developing in a Windows environment, then your production environment is also likely to be a Microsoft server using IIS. Why would you use Tomcat? But you may choose to use Tomcat, if developing in a Linux environment.
The problems I had may not have been of concern to a new CF user, as they would have just accepted that everything was case sensitive.
In my case, I've got many legacy applications, and no way would I want to go through each one tidying up filenames, just so I can set up a new development environment.
The fix that I applied may or may not still be a security issue, but it really is Adobe's responsibility to make that clear in their documentation, especially given that this has been an issue for 3 years.
Fair comment about posting bugs. I have done that with a previous issue (also to do with installation and configuration), and I will do so with this one as well.
Just for the record, my home page filename was Index.cfm, and the welcome-file-list name was index.cfm. I have always used .cfm in lowercase.
Finally, a big thank you for your contribution to the cf community.
To be clear for subsequent readers, this is only about the built-in web server. If you're using an external web server (IIS or Apache), you'd handle the setup of multiple hosts THERE, not within CF's config.
I have no idea what to put in here. Can you help please?
I installed Coldfusion 2016 development version with built-in web server. I followed the instructions and everything is working on the dev server locally when hitting http://127.0.0.1/ I can also access it by local IP of that machine on which it's installed (in my case specifically http://10.0.0.23/) BUT when I try to access it by its local IP from another machine that that is on the same network, i get "Can't reach the server" in the browser.
Just to clarify: I updated to port to 80, so it's not the forgetting the port issue. Also, I have Glassfish server installed (which is obviously off and not running when I start the CF server) and when I run that Glassfish server I can easily access it on my local network by local IP. So it isn't a firewall, nor network issue.
So there is something obviously in configuration in CF server's built in server that's preventing the server to be accessed from other LAN machines on the same network, but only the one it's installed all.
Do you have any idea what it could be? I need to be able to access my development server from different machines on the same LAN, so any help/ideas on how to make it happen while using CF built in web server is very appreciated.
In both cases, I really think you'll get the problem solved best and fasted via the remote consulting I offer, where I have no minimum (and this may take less than 15 mins once I can see things with you), and I have a satisfaction guarantee so you won't pay for any time you don't feel is valuable. So what have you got to lose?
And in case you're dissuaded from considering this because "you can't give me remote access", you do not need to, nor will you create any account for me or open any firewall hole for me. We would use a screensharing app, like webex, gotomeeting, or my long-time favorite, join.me.)
For more on my rates, approach, satisfaction guarantee, and more, see http://www.carehart....
I really would look forward to helping solve your problems.
In my organisation we use cold fusion 11 in-build tomcat, I have a question that what configuration should we do in tomcat to increase the performance, tuning, deployment of jar war application easliy.
If possible please refer some pdf's or web links.
Thank you.
This post was written in 2012, regarding CF10. Since then, CF2016 now runs on Tomcat 8, and as such there's a difference regarding how to setup such "virtual directories", or what in Tomcat 7 (on CF10 and 11) were called and configured as "aliases". (This was discussed further in the Adobe article, also from the CF10 launch, which I pointed to above.)
Well, for CF2016 and Tomcat 8, you would want to instead use what is now a RESOURCE element.
I plan to do a new blog post on this, but until then a simple example is that you could put this line inside the CONTEXT element within the context.xml file (in the runtime/conf folder of your CF cfusion or instance directory):
<Resources className="org.apache.catalina.webresources.StandardRoot">
<PreResources base="c:\mypath" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/myalias" />
</Resources>
I'm showing a windows drive example, of course. This works for Linux paths as well, naturally. And note that it can point to a folder outside of the CF directory structure (as long as the user running CF has permissions to access such a folder).
See these Tomcat resources for more :
https://tomcat.apach...
https://tomcat.apach...
(While the RESOURCES element was indeed in Tomcat 7, this specific class about a dirresourceset was NOT. And while Tomcat 8 also adds an available VirtualDirContext class that can ALSO be pointed to as a resource, it does NOT achieve the same objective, despite its name.)
And I have confirmed that while the "base" value above is NOT case-sensitive (for the drive or the path), the webappmount value IS case-sensitive. (And while that can be "allowed" with an available "allowLinking" attribute, there are security reasons NOT to use that. See that first Tomcat resource for an explanation.)
Finally, to be clear, yes, this is for running CFM files, not just for "static" files. I add that because that first doc page above refers to it loading "static resources", but notice it goes on to refer to that as "HTML, JSP, and" ... "other static files". The fact that they regard a JSP as "static" is all we need to know, relative to a CFM file being of the same ilk (to Tomcat). I suspect what they'd regard as "not static" would be servlets and other java classes, and we as CFers don't need to worry about that.
And now you see why I said this deserved its own blog post! :-) But I wanted to post this here in the meantime, both to help readers and to perhaps get feedback from any past commenters on this, in case they may have more to share on this development.
<Context path="/" docBase="C:\ColdFusion2016\cfusion\wwwroot" WorkDir="C:\ColdFusion2016\cfusion\runtime\conf\Catalina\localhost\tmp">
<Resources className="org.apache.catalina.webresources.StandardRoot">
<PostResources base="C:\ABC\virtualDir" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/VirtDir" />
</Resources>
</Context>
But here's good news: as for a good single starting point for doing it, and from a CF perspective, see the CF2018 Lockdown Guide, at https://www.adobe.co..., and see the section "To run the Builtin Web Server over TLS". Note that this section and its content is NOT covered in the CF2016 and earlier lockdown guides.
That should get you going, and I could leave it at that, but in case you or others read that and find something still doesn't work (such as if you are on some earlier version than CF2018), or if something changes in the future that somehow makes it "not enough", read on.
There is much that could be said about this subject (of enabling SSL/TLS for the CF Admin/built-in web server (BIWS), and troubles people have had in the past), and there's no single good resource to point to that covers it all. I should do a post at some point. Until then, here are some observations.
One key point to keep in mind as you go looking for resources about this, is that the built-in web server in CF (10 and above) is in fact the TOMCAT web server, so you can find plenty of info on the web about setting up SSL for that--and it would apply to CF as well. At least, in broad strokes. (There is also lots of OLD info about "securing the CF Admin", which will be instead about CF9 or earlier, which used the jrun built-in web server.)
That said, even in more recent CF versions there have still been issues (such as in earlier versions of CF, like CF2016 before its update 2) where CF's included jsafe library made it so that folks who even found and followed "correct" steps still found things not working, unless they added needed "ciphers" to the connector xml entry, which is discussed in the resource above. For more on that, see a forum thread reply from Pete Freitag (who also writes the CF Lockdown Guides), https://forums.adobe...
Also, most of the resources on the topic show only using a self-signed certificate for enabling SSL for the BIWS. That's fine for dev or local-only use, but clearly some may need to use a real certificate for use with a real domain, and for that you need to see Java and/or Tomcat resources for more info on doing that specifically.
Speaking of the process of creating a self-signed cert, many of the resources you will find on the web on the topic (of enabling SSL for the CF admin) will refer to this step as "creating a keystore", when in fact they show instead creating a *certificate*, and then PUTTING it in a keystore, and then POINTING to that (in the connector xml element, such as referred to in the resource above).
Finally, they often show using the keytool with a -genkey argument, which will work, but if you look at the help for the keytool you will see it's not listed as a valid argument. Instead, it's an alias (old name) for the -genkeypair argument.
All these (and more) have led to confusion on the topic. But we are certainly getting into the territory of "almost another blog post in this comment", so I will leave it at that. :-)
Finally, it's worth noting that one can try to force CF to allow access to the CF Admin by way of your external web server (IIS or Apache), instead, which is the way things worked by default prior to CF2016, when Adobe decided to instead close that door by default and require use of the BIWS instead (for security reasons). That can seem compelling, as one could then setup SSL there (in that external web server, instead of in CF), and could also use that web server's controls to try to limit access to the Admin, such as via ip address/ranges, authentication, and so on. All that would be better documented (as it has nothing to do with CF, specifically).
I'm not saying that's a better option, just that it may seem appealing as an option for some folks. But I will warn that if you try to go about making that happen (overriding CF's protections, like removing the block on calls to CFIDE in the uriworkermap.properties and adding back a needed virtual directory/alias to point to the CFIDE/administrator folder), just beware that such tweaks will NOT be managed and may well be REMOVED by the CF WSCONFIG tool if you find you (or a colleague) might need to run it again in the future. Forewarned is forearmed.
Hope all the above helps anyone seeking info on "securing" the CF Admin. Again, I should create a new post on it. Let me see if I get any useful comments here, until then, especially if you may set out to proceed with it, MLipenk.