This informations is the result of questions/answers chat in https://cfml.slack.com/ with Brad Woods
Q1 - What is the place of Runwar in the whole CommandBox Architecture?
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 Catalina
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.
Q2 - why do you 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 its 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 which decides what pieces to wire up
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
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.