I pretty frequently have directories with multiple server-xxx.json files, to allow running any supported environment there. I lunch them initially by their script, then by their name as defined in the .json files.
Thing is, when I say ‘stop --local’ there, CommandBox often responds that some other one of those servers is already stopped, so it does nothing, when in fact one of them IS actually running. It seems to have an idea of which environment is the default server for that directory (there is no default in my mind), and if that one isn’t running, then there’s nothing to stop.
I’d suggest that ‘stop --local’ should stop any running server(s) that target that directory location.
Make sense?
Thanks again for these tools, really great stuff!
Actually, “stop --local” isn’t even a real command. Well, “stop” is a real command, but there’s no “local” parameter to it. Run the help command by typing “stop ?” and you’ll see what the valid commands are. So CommandBox was basically ignoring your --local bit and just trying to stop the default server in that directory.
We added --local to the “server list” command a couple releases ago, and I like the idea of adding it to some of the other command where it makes sense. Can you please put in a ticket for this? I think it could make sense for the following commands. What do you say?
- server start --local (Start all the servers defined for this directory)
- server stop --local (stop all the server in this dir)
- server status ( get status for all the local servers)
- server restart --local (restart all the local servers)
- server forget --local (forget all the servers in this folder)
Thanks!
~Brad
ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Interesting. Text match filtering works for start/stop/etc, like for list, doesn’t it? I just assumed that – local did too, my bad.
So I guess the second-order feature request is to complain when unsupported parameters are passed to cmds 
I’ll file those issues when I get a chance.
Dave
> Text match filtering works for start/stop/etc, like for list, doesn’t it?
Actually, no. The “server list” command is the only one that behaves like a search. All other server commands have historically applied to a single server as identified by the name, the web root directory, or the server.json file.
> So I guess the second-order feature request is to complain when unsupported parameters are passed to cmds
Well, I’ve thought about that before and left it the way it is on purpose. Since CommandBox commands translate directly to a CFC function in CFML, it’s very handy to have a generic command that can act dynamically based on arbitrary inputs. Examples of this are:
package set foo=bar
cat file1.txt file2.txt file3.txt file345324.txt
server set name=test web.http.port=80 brad=wood luis=majano dave=merrill
task run :arg1=value1 :arg2=value2 :arg3=value3 :whatever=whocares
Each of those commands (there’s more than just those) act dynamically on the argument scope that comes into the CFC method to allow for very dynamic usage. If CommandBox forced me to explicitly declare every parameter that might be passed in, those commands would no longer work,
Thanks!
~Brad
ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Understood, I guess this one case is somewhat the oddball.