You don’t need to install Lucee, because CommandBox will do everything(!!!) for you:After installing CommandBox, just open a terminal session, change into your wwwroot, and type box server start. Then lay back, watch the console and you’ll see CommandBox in action. It will do all the rest: It will download the latest Lucee version and start running Lucee with its own embedded server undertow (instead of Tomcat).
What is sometimes a little confusing for newcomers is, that running Lucee with CommandBox is so freaky simple!!! You just need to install CommandBox, open the terminal session and run it with box server start.
To make things even simpler, you can add all your settings (even URLrewrites!!!) into a server.json file and put it into your wwwroot. Commandbox will run Lucee and the embedded server with all those settings.
And just to add here, ColdBox is an MVC framework you use in your code to help write web apps and REST APIs. CommandBox is a CLI that starts servers. And while these tools work very well together, they do not require each other and are totally separate things.
Depends on what you mean when you say “server home”. if you just want to access the Lucee admin UI, you can use the menu in your system tray for the server and you’ll find a link under the “open” submenu. If you mean the actual folder on disk where Lucee’s files are-- every server you start in CommandBox has a separate server home and you can actually find it in the same place of the tray menu I mentioned above.
Assuming you meant “CommandBox CLI” and not “ColdBox”, then yes that is a perfectly reasonable use-case. Really, no matter how many apps you have, generally each project folder (which is likely also your Git repo) has
the code
the server.json
the .cfconfig.json
Maybe even a box.json for your dependencies (ColdBox would go here )
and then each project root is a completely stand-alone project and you can simply cd into that folder and run server start, server stop, server log --follow, etc, etc to interact with that server.
You’re absolutely right… I mistyped… I am starting off my use of CommandBox!
Thanks very much for your time with replying, Brad - I really appreciate it.
I got “thrown” by two things…
I “thought” I started box in the “approot” - but obviously didn’t.
And;
When I first started box I configured an Admin password - but got prompted for importing one…
So I “thought” (again) that there was something amiss with how I was running it…
I didn’t realise that setting the password on start - didn’t do the import automatically for you…
So once I started in the correct directory and imported the password.txt (which was created by box) - everything was exactly as advertised.
I was initially determined to “replicate”, as close as possible, our production servers on my local machine and was adamant that I was going to do “something other” than CommandBox - since we don’t use it in production…
I have come to realise that was just “stubbornness” and I, sincerely, thank everyone involved with CommandBox for the work that has been put into it - and making it available for free, too.
I am really impressed it, by it as a solution and CFConfig is really awesome, too and my personal “driver” for using CommandBox, locally.
Again thanks to everyone - I feel like a converted cult member!
which will show all the servers you’ve ever started, what folder their in, what CF engine their on, what ports they are listening to, etc, etc to help notice if you have an errant server running in the wrong place.
Also, installing bullet train will give you SO MUCH extra information about the current directory you’re in on your server that it’s nearly impossible to get confused about where you are.
Just cd’ing into a directory will intsantly tell you
what folder you’re in
the name and version of the project in that folder (read from box.json)
The Engine and running/stopped status of any server in that folder
The branch and status of any Git repo in that folder
Just to be clear, CFConfig doesn’t ever create a password.txt file. It hashes the plaintext password and stores it directly in the XML config files for Lucee. The password.txt file is really only something that people unfortunate enough to not be using CFConfig must deal with.
From a documentation perspective I still think you need something like;
(obviously my wording is "pseudo-documentation!!)
Upon initial use of a new server, even if you have used, cfconfig set adminPassword=XXXX, you will get prompted to import the password… this is cool and normal : go ahead and use the import button!
This makes no sense at all and I would never recommend people try and use that horrible password.txt file. Can you perhaps document exactly what you’re doing that isn’t working for you, because I start fresh Lucee servers all the time and I’ve never needed to use the password.txt file.
It almost makes it sound above like you are
creating an empty folder with no server at all
randomly running a cfconfig set command on… thin air?
Then starting a server
That obviously wouldn’t work because there needs to be a server in existence in order to set its password! You can, of course, set the password after the server has started, but unless you’ve configured Lucee to watch the XML files on disk for changes, you’d need to restart Lucee to pick up this change.
Then you have the option of having your password (either hashed, or plain text, your choice) in your .cfconfig.json file in the web root, which will be loaded automatically when the server starts.
And finally, you can set an env var, either a one-off like so:
set cfconfig_adminPassword=mypass
server start
and CFConfig will detect and import it. Or my favoriate method which is to set a global env var as a one-time thing which is always present in my CLI and auto-imports into every server I ever start.
# one time setup
install commandbox-dotenv
propertyFile set ~/.box.env cfconfig_adminPassword password
# applies now and to forever
server start
You really haven’t been clear about what you’re doing so it’s hard to say why it isn’t working for you, but there are many better ways to get a password set with little effort and none of them involve that password.txt file
Yeah, Lucee reads the XML files on startup and form then on out it uses the config that’s stored in memory. So if the XML files change on disk, Lucee isn’t looking at them unless you’ve told it to.
Note, this still requires that the server has been started at least once since you can’t set config into a server that doesn’t exist (well, not like that anyway). Which is why I recommend the global .env file approach.
)
