In my continuing efforts to use The Smith Engine to the best of my ability, I've been attempting to install Tomcat so that I can run CF on port 80. The fine folks on the Smith team have provided this page with directions for downloading and installing Tomcat, the Apache-Tomcat connector, and so on.
The URLs they provide for file download are wrong -- they 404. You probably want this url for the correct version of Tomcat, and here's a url for the tomcat connector that actually works as I'm writing this. You can get current URL's by checking this page and this page, respectively. Note that you want the "core" distribution of Tomcat.
The instructions from Smith don't mention that there is a new version of Tomcat available, and based on the chart under the Tomcat Versions heading of the Tomcat home page, I'm guessing you want to stick with Tomcat 5.5 -- because if Smith required 6.x for the latest Servlet/JSP spec functionality, then the documentation would probably use 6.x as an example. I suppose it might work with 6.x, but I grabbed the latest 5.5.x and it works for me.
Once you've got the files downloaded and you start to configure, the first problem you'll run into is that the Smith documentation assumes you're using "standard" apache. Since you're using XAMPP, your paths are different. Ok, so where do we find apxs when using XAMPP? Here:
/opt/lampp/bin/apxs -- assuming you installed XAMPP to the standard location of
/opt. Wherever you installed it, the path would then be
However, you'll probably run into errors (like this guy) that looks like this:
need to check for Perl first, apxs depends on it...
checking for perl... /usr/bin/perl
could not find /opt/lampp/bin/apxs
configure: error: You must specify a valid --with-apxs path
To resolve this, you'll need the developer package for XAMPP. You can find a current link for that right here -- but as of right now, you can just use this URL. To be honest, I'm not perfectly clear on why you need the developer package, because apxs is at the location you're specifying. My best guess is that supporting files aren't in place or that the version of apxs included is incorrect or incomplete. Either way, simply unpacking the developer package into your
/opt folder puts whatever needs to be in place into place, and the configure command will work.
Then just make, make install, and you're off running... through the rest of the instructions.
Published 2007-11-27 @ 06:08 in
There has been some recent discussion about why ColdFusion isn't free/OS on CFInsider. I think that's a very interesting and valuable post... and I intend to use its information as more arsenal to sell my clients on CF. However, sometimes cost really is prohibitive... And what if there was an open source CFML alternative?
By now most CF developers probably know about The Smith Project. It's an open source CF engine built in Java. I was also happy to learn that it is very easy to install and configure, and the features are more or less caught up to about version 6.1 of retail ColdFusion. I've been using it for a few weeks now and have come to the conclusion...that although it's a tremendous effort and an excellent offering considering the price, it's not ready for enterprise use.
I'm writing an accounting application for a small business I run. This means that it will be used by myself and my partner, and that we can live without all of the cool new features in CF8. So far I've only run into a few unsupported things that caught me off guard, and I have been pleasantly surprised with how smooth and fast my application has been running.
I've been using the built in web server because integrating with Apache -- from what I understand -- can only be accomplished with Tomcat... something I had a traumatic experience with in college. And why bother running both Apache and Tomcat when the integrated web server runs just fine for my user base of two people? That sounds like a waste of resources. Now, I will probably want to deploy my application onto a server running apache and several virtual hosts, so having the option of installing Tomcat and deploying instances of Smith into specific virtual hosts by deploying the latest WAR file is pretty appealing, and I may go begrudgingly down that road. It's nice to know I have the option.
As far as the built in web server, it is very fast. On average, my page load times have been in the double-digit milliseconds or less -- even when executing complex queries, looping over them, running sub-queries and building large, complex pages. By default it runs on port 8081, but you can change this with a command line parameter in your startup script, or by editing a config file. I have noticed that sometimes form post responses seem to hang for a few seconds after the response is delivered. Meaning that after I submit my form and the response is sent, the page renders, and the progress bar in FireFox is still sitting at 99% waiting for the connection to be closed. I'm not positive that the internal web server is at fault, but it's the most likely candidate.
There are things that just haven't been implemented yet. CFRegistry is one of those, but thankfully it's not a feature I need -- and couldn't use anyway, as I'm running Smith on a Debian server. There are things that are just old school.
CFHTTP doesn't use the newish attribute
result, but rather puts the result into a struct called CFHTTP. (However,
CFFILE does use the
variable attribute.) Some things are just different. Here's what the debug output looks like.
Some things are just buggy. For example, currently you can't enter a mail server (format: username:password@server:port) that uses a username which includes an '@' symbol, which stops you from using any servers where you have to authenticate using your full email address as your username. I've reported the issue and hope to see a fix go in soon.
What I've been most pleased with has been the active community, however small, surrounding Smith. It seems like development is ongoing and at a respectable if not aggressive rate. The source code is available in SVN (Or is it CVS? I've seen both mentioned in their forums) and every time I post about a problem I'm having I get a reasonably quick response that either explains what I'm doing wrong, or explains the bug in Smith, along with a note that the responder has filed a bug report and usually even proposed a fix which could be included in the next release.
The biggest thing that seems to be missing is documentation on exactly how Smith CFML differs from Adobe CFML, resulting in the need to search their forums for posts to see if anyone has already asked your question and if not, to post and ask it. Of course, the community is welcome to contribute that documentation, and it appears that someone may have already started.
All in all, if you would rather not spend the money on CF then I think it is definitely worth your time to try out the Smith Engine. Even moreso if you're not developing an enterprise application, and/or have the option and drive to develop around some quirks.
Update: I know it's only been a matter of hours since I originally posted this, but the Smith forum community has fixed the mail server connection string issue for me! They say that it's not likely to be patched into the ongoing release for Open Mail Relay-related reasons (that I disagree with), but it was a simple 2-line source code change and about an hour's worth of work to download the latest source, download and install the Java2 SDK and ANT, and recompile Smith... and it works like a charm. This is exactly the kind of community-vibe that I mentioned above. You can read the thread I posted and the instructions I got back on how to make the edit myself here.
Published 2007-11-20 @ 02:43 in