[Logo] smithproject.org
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
Smith ColdFusion and Mac OS X - A Terrible Combination  XML
Forum Index -> General Discussion
Author Message
BuildSmart



Joined: 07/10/2007 07:27:15
Messages: 23
Offline

For those looking for a free ColdFusion engine to run on Mac OS X I can confirm the following.

The SmithCF engine will run on Mac OS X and you can even get it working with Tomcat as long as you're not intending to provide the service for multiple virtual hosts and that is about as far as it goes.

Don't misunderstand me, it works and it can be useable on a small scale (1 or 2 virtual hosts) and the engine is pretty much compatible with the big boys like Adobe and BlueDragon (with some minor code quirks) provided you don't mind the complicated configuration involved in utilizing it.

So far, the only way I've been able to verify it works is that it's run as stand-alone on some obscure port like 8081 and you give up all apache functionality which is a terrible implementation for any hosting environment and the other method involves Tomcat, while this can be made to work, there are several issues that prevent it's implementation if you're planing on hosting more than a couple of domains.

The first issue is that of configuration, aside from configuring apache with your virtualhosts and their corresponding document roots you also need to create an identical configuration in Tomcat for each virtual host and that in itself is an unrealistic solution when more than a couple of sites are involved.

The other issue is that all of your coldfusion scripts are run out of the Tomcat virtualhost root for it's corresponding apache virtualhost and if these are two seperate locations then it only complicates any file structure you might wish to implement.

The third issue is in using mod_proxy to alleviate the Tomcat configuration problems and while this does seem to provide a better solution varying host tree structureseem to confuse it easily between multiple virtual hosts and, security becomes a real concern due to the vulnerabilties introduced by the use of mod_proxy and thus makes it a poor solution for any real hosting environment.


The fact that no module is available to directly integrate SmithCF with apache makes implementation in any kind of hosting environment almost impossible due to the loss of flexibility and functionality.


Another interesting matter is in the development teams lack of knowledge with regards to their proposed method of implementation and the lack of ability to answer questions directly related to the configuration of their proposed method of implementation.

So it's basically a ColdFusion engine that has a poor choice of implementation, no documentation outlining other possible methods of implementation and no documentation outlining configuration and/or usage in Mac OS X.


I've taken the SmithCF engine source, made some modifications to some classes, renamed a few things and generated what I now call AppleCF which is a Mac specific implementation of the Smith ColdFusion engine along with Jetty, a startup item to get it running with as little work as possible leaving only the method of integration up to you, all wrapped up in an Apple installer that I'll be making publicly available in the near future for those interested in deploying it.

My next plan of attack is to implement a module that will integrate the CF engine with apache, when I have achieved this I will make the module publicly available for apache 1.3.33 and apache 2.0.53 in a universal binary (the versions of apache supplied by Apple) and the module will only work with the Apple specific version of the SmithCF engine (AppleCF).

Unfortunately, when I do have a working solution I wont be releasing the source code so that other platforms may take advantage of this implementation method.

You may feel I am selfish or prejudicial in my directions but, I feel that supporting other platforms that don't assist or help to support mine is a reasonable and fair practice.

-- BuildSmart
m.obradovic



Joined: 22/01/2007 14:04:55
Messages: 6
Offline

BuildSmart wrote:
...I've taken the SmithCF engine source, made some modifications to some classes, renamed a few things and generated what I now call AppleCF which is a Mac specific implementation of the Smith ColdFusion engine along with Jetty, a startup item to get it running with as little work as possible leaving only the method of integration up to you, all wrapped up in an Apple installer that I'll be making publicly available in the near future for those interested in deploying it...

...Unfortunately, when I do have a working solution I wont be releasing the source code so that other platforms may take advantage of this implementation method.
 


Hi BuildSmart,

I'm not much into legislation, but I guess that would infringe the Smith GPL license.

I think you need to open source AppleCF, because that is required by the GPL license.


BuildSmart



Joined: 07/10/2007 07:27:15
Messages: 23
Offline

m.obradovic wrote:

BuildSmart wrote:
...I've taken the SmithCF engine source, made some modifications to some classes, renamed a few things and generated what I now call AppleCF which is a Mac specific implementation of the Smith ColdFusion engine along with Jetty, a startup item to get it running with as little work as possible leaving only the method of integration up to you, all wrapped up in an Apple installer that I'll be making publicly available in the near future for those interested in deploying it...

...Unfortunately, when I do have a working solution I wont be releasing the source code so that other platforms may take advantage of this implementation method.
 


Hi BuildSmart,

I'm not much into legislation, but I guess that would infringe the Smith GPL license.

I think you need to open source AppleCF, because that is required by the GPL license.


 
It is open source, I have not altered the license and I'm not releasing it under a different license, I'll provide the finished product in a Mac OSX acceptable distribution format and it will be covered by the SmithCF license because it is there project and they own it.

As long as I respect the license that the project is released under, there is no issue with distribution, I'm not claiming it as my own work and I do credit the smith project for their efforts, what I am not obligated to do is provide the modifications I made to any of the code, any of the modifications I do release is done as a courtesy.

I am now at a point where I have an apache mod_smithcf module and require the assistance of the projects dev group to finalize the implementation so that everyone can take advantage of it, I may grant the smith project the rights to distribute this module in binary format or I may allow them to distribute the module in source format, this has not yet been decided and is dependant upon their willingness to implement such a module implementation or I end up paying someone more fluent in java to make the necessary adjustments to the engine or adding some classes and provide a distribution that is specific to my OS of choice, either way, I get what I need which may be selfish but it is the basis of my motivation in this project.

It all boils down to getting an implementation that is usable in a virtual hosting environment without the use of Tomcat or some other restrive method of implementation that requires more configuration than setting up apache virtualhosts without sacrificing functionality or security.

mod_proxy and mod_rewrite are not acceptable due to the security vulnerabilities they introduce and going to a stand-alone module/engine solution is probably the smart approach and will yield the best results.

If the project wishes to take on a more readily deployable solution and want to work with me on it then great, everyone will benefit, if not I'll go it alone and at least I'll benefit from it but the bottom line is, I refuse to accept that the project can't be more easily deployable in a virtual hosting environment and turned into a ColdFusion contender and join the ranks of the big boys like Adobe and BlueDragon.

I've written to the team and I'm ready to take it to the next step, we'll see what transpires and I'll keep everyone apprised of status.

-- BuildSmart
BuildSmart



Joined: 07/10/2007 07:27:15
Messages: 23
Offline

Well, I just heard back from the smith project via e-mail, seems they're too busy to get involved.

I don't think I'll find the help I require here since the majority of the users are just that, users trying to implement the SmithCF engine and I don't believe poses the level of knowledge required to finish the product.

What does this mean, well, I guess it means that I'm going to have to pay someone to get the help I need in finishing things up cause I'd like a solution now.

It also means everyone will have to be satisfied with the cumbersome/troublesome Tomcat solution that make deployment in a hosting environment unrealistic and it means that there will not be any module publicly or openly available.

I wish everyone else interested in the project good luck and hope that the project will eventually provide a sensible and intelligent solution where the SmithCF engine can be utilized with a different method than Tomcat.



I will still provide a Mac OS X installer for the Apple modified SmithCF engine and may even provide updates from time to time but that will be the extend of my involvment in the public project.

-- BuildSmart
 
Forum Index -> General Discussion
Go to:   
Powered by JForum 2.1.6 © JForum Team