http://coldfusion.com logo
Join Slack
Powered by
Thanks a lot
# box-products
f
Thanks a lot
j
@fman The answers to your questions:
1. When I’m using CommandBox I’m not using Adobe Coldfusion
CommandBox is just a CLI orchestration tool. You can run any CFML server product you wish to. We have even used it to run old Blue Dragon servers
2. I’m getting a ‘Adobe Coldfusion’ Copy from ortus site
No. You are getting the officially distributed J2EE deployment of Adobe Coldfusion - just packaged to run on CommandBox
Can I use CommandBox in production? We have a Adobe SUpport Contract and I do not know if they will provide support
Yes. Absolutely. The deployment is simply a J2EE deployment, rather than a standalone deployment. Adobe supports this. That said, to run Adobe J2EE deployments in production requires an Enterprise license
CommandBox is not using Tomcat, but wildfly, it will be ok to manage the load of a production site
Absolutely, yes. There are thousands of instances of CFML apps using CommandBox to run them in production. I find JBOSS undertow to be far superior and more efficient than Tomcat.
cc/ @bdw429s if he has anything additional to chime in on
b
.
@fman Everything Jon said is 100% correct. A J2E deployment is a valid and supported method of deploying Adobe ColdFusion, and by "supported", I mean supported by Adobe themselves. We have many clients with ACF deployed on CommandBox for production sites and they get regular normal support from Adobe for matters related to the ACF engine and we support them for matters related to the servlet (CommandBox). Some of these customers I'm referring to have paid Adobe support plans which are fully honored by Adobe. And, FWIW, most of them have paid Ortus support as well 😉
The WAR packages you start with CommandBox are literally the WAR deployment as Adobe ships it with their official updaters applied. Do don't modify them outside of that so it's not a "copy", it is an actual Adobe WAR deploy.
And as far as Undertow performance-- it has a lot more feathers in its cap than our existing users. Undertow is a professionally supported product of RedHat/JBoss and is used to power their Enterprise-level Wildfly server, which is the core of their JBoss EAP (Enterprise Application Platform) which is deployed all over the internet, supported by one of the largest names in Java software today
Undertow is incredibly capable and blazing fast. I've actually done head-to-head tests with Undertow, comparing it's serving of static files to Apache and IIS and it matched their throughput exactly. Furthermore, I added CFML (both Adobe and Lucee) to the TechEmpower framework benchmarks which includes basically every language/platform/framework ever written in a side by side automated performance test. I powered the CF engines using our Ortus Docker container, running CommandBox/Undertow, and CFML performed amazing, performing faster than Node, Groovy, Ruby on Rails, Laraval PHP, and Django Python in some tests. https://community.ortussolutions.com/t/how-does-cfml-really-perform-compared-to-other-languages/9325 And this was all on a CommandBox/Undertow-powered web server. So, there is no concern about performance or quality of that Redhat-powered servlet container.
❤️ 2
👍🏼 1
@fman Since this are valid questions that I'm sure others have asked, do you mind if I create a post in our community forum just generically addressing these. You can also point any co-workers to it who may not be in this Slack team.
f
@bdw429s First thanks a lot for your help. I will be absolutely GREAT if you can create a post with all this details. I think is a super Idea, because many other users that wants FULLY UNDERSTAND pro and cons of CommandBox will appreciate it a lot. Many,Many Thanks
👍 1
@jclausen Thanks a lot for your help
🙂 1
b
Please let me know if there are other questions and we'll happily address them
f
Brad, I would like, if possible to understand what is the place of runwar in the whole architecture. All the time (my fault) I've thought that runwar took the place of Tomcat. Would you mind clarifying this? Thanks a lot again
b
@fman Honestly, there are a few moving parts and the difference is largely moot. • CommandBox is the CLI (written and maintained by Ortus) for orchestrating deployments • Runwar is a Java tool written by Denny Valiant and now maintained by Ortus which encapsulates servers started by the CLI • Runwar embeds Undertow, which is a service layer for creating servlet deployments. Undertow provides both the web server and servlet container So Runwar would be more/less the equivalent to Tomcat and Undertow would be more/less the equivalent to Catlina
We've packaged them all together so you really just need ot know about "server start" and we take care of the rest 🙂
The J2E stuff happening under the covers of ColdFusion is a black box to most CF users who don't even understand the demarcations between Tomcat/Catalina/ColdFusion so I don't generally bother documenting the stuff under the covers of CommandBox, though I'm happy to explain it!
And FWIW, CommandBox does not use WildFly directly. We use Undertow directly. Wildfly is more of an equiv to Tomcat. Undertow is just a service layer in a collection of jars which you embed into an app of your own.
f
Well, to be honest this is the first time I know about the difference between TomCat and Catalina. I'm very interested in what is happening under the hood because I need to be 100% sure that we are using something really solid. The company where I work (TESISQUARE, in Italy, just for the records Luis Majano has provided consultancy time ago when he was in a trip to Milan) builds an enterprise application (TESISQUARE PLATFORM) for very big customers, then performance and reliability is a MUST not an option.
I'm very curious about the choice to do not use Wildfly directly.
IMHO all this info you are sharing here, is extremely useful and may be can be an addon on the CommandBox documentation
j
Tomcat has actually only been packaged with ACF standalone installers since Coldfusion 10. Before that they used to use a self-manufactured servlet container called JRun. Basically, as long as the container is J2E compliant, a Coldfusion WAR file will run on it.
f
@jclausen we have been using ACF since version 4.5, the I remember JRUN, and when trying to run ACF on Tomcat was some kind of hacking
☝️ 1
b
I'm very curious about the choice to do not use Wildfly directly.
Because we could not create the deep level of integration that we get using an off-the-shelf servlet engine. With any out-of-the box servlet, you are stuck with • their installation • their bootstrapping • their config files • their web.xml parsing • their settings/config/xml files Undertow gives us all the power of WIldfly, but in our own packaging which is custom built for CF engines, the way we need it to work • we control how it's bootstrapped • We control how the deployments are made • we control the web.xml parsing which enables many CF-specific behaviors as well as overrides • we control the custom resource manager (which Adobe also does in their custom build of Tomcat) • we control the config files to be our server.json • we integrate things like the tray icon • we can support our own env var conventions • we can add in our custom server rules for CF-specific lock downs and rewrites
There is basically a TON of customizations we're able to do by using all the features Undertow provides, but packing it in our own Java app (Runwar) which decides what pieces to wire up
f
@bdw429s ok, it's seems I have problems "digesting" the use of runwar (again my fault)
b
Undertow is like a giant box of legos. It has handlers for everything imaginable-- client cert auth, predicate language, header management, proxy headers, etc. We get to build up the pieces that make the most sense for a CF application and tie it all to our config files very tightly
Runwar is the Java app which spins up Undertow and ties all the pieces together to create the actual server deployments. You basically can't use undertow by itself, it's just a pile of jars that sit there. You have to compile Java code of your creation to actually use undertow. And that is where runwar comes in.
This is what gives us the power to have CLI settings like
Copy code
server set web.blockCFAdmin=true
and we automatically plug in the plumbing to secure your CF and Lucee admins. We have this power and capability because we control the entire stack from the ground up
Lucee doesn't have that power as they bundle stock tomcat and depend on its config. Adobe technically could do stuff like that as they have a custom forked build of Tomcat, but they don't have the creative foresight to build those sort of features in and they basically just use Tomcat as-is with a custom resource manager to create the behavior that ModCFML mimics
This is why Ortus is ahead of the curve and has been for years on the most flexible and powerful way to deploy CF apps with a plugable architecture for • the entire web server config • rewrites • fusion reactor integration • CFConfig integration • dotenv integration • packaged deployments • full env var support for every configurable item of the server and CF config Adobe and Lucee don't come close to any of this and it's because they're just using an off-the-shelf servlet solution which is not created from the ground up with CF deploys in mind.
@fman Does this help answer?
f
@bdw429s Absolutely. Again my suggestion is: if you can add all this information as an specific chapter in commandBox documentation it will be FANTASTIC and very very useful
b
@fman I can see where we put it, but to be honest 95% of people don't really understand the inner workings of servers and don't care so I have to weigh what adds value to the docs and what just adds confusion. We are working on a CommandBox Pro offering thought right now, which is a professionally supported version of CommandBox that comes with support and extra features. We're looking at putting some of this info in that marketing.
We already have companies using CommandBox Pro in production as a full replacement for their web server (Nginx), the largest of which is ESRI
f
Brad: any idea of cost of CommandBox Pro? what will be the difference with standard CommandBox? do you still will distribute standard CommandBox?
b
any idea of cost of CommandBox Pro?
I think this is still a work in progress. Please reach out to @jreyben if you'd like to discuss it
what will be the difference with standard CommandBox?
We're building this marketing as we speak. The biggest difference is the support, just like any other open source project that also has a commercial version like RHEL or EAP. There will also be some bundled bundles and features that we include
do you still will distribute standard CommandBox?
Yes, of course! CommandBox will always be free open source. This is just an offering to larger companies who want to feel like they're entering into more of a contract with a company guaranteeing support etc. It's just like purchasing Nginx+ when you could just use the free version. You pay money for support, a few extra features, and peace of mind that the company has your back. @fman
f
Brad: thanks a lot for your answers
👍 1
Brad: it's ok for you I add the main concepts of this conversation in the post you have done?
have a nice week end
b
Sure!
f
Hi, done!
👍 1
5 Views
Open in Slack
PreviousNext
Powered by