I’ve got an app that hits the wrong port when I type fwreinit in CommandBox.
I tried forgetting the server and ensuring the folder was removed from C:\Users\username\ .CommandBox\server
I double-checked the server.json file and it shows port 60301. However, every time, I execute the command it tries to execute 127.0.0.1:63789/?fwreinit=1
I searched the entire project folder for an instance of 63789 but I can’t find any.
Aside from clearing out the server in .CommandBox\server\ and ensuring the server.json file is configured correctly, is there another place I should be checking?
Glad to hear. For anyone else running into this in the future, the code in the reinit command uses the following details to create the reinit URL, from the first server it finds in the web root.
var thisURL = "#serverInfo.host#:#serverInfo.port#/?fwreinit=#arguments.password#";
You can find these details for a server with the command
@Andrew_Kretzer, your question might work better as a separate thread, however, I agree with you that it would be cool if fwreinit could be pointed to a subfolder within your project root.
Something like, in your case, fwreinit path=www/. However, that’s not possible as of today AFAIK.
This ability would be extremely beneficial for people who use the Ortus Module Template so that they could launch the server from the project root, but fwreinit would execute in the test-harness folder.
Perhaps this could be a new server.json setting?
Edit:
The way I solve this now, while developing a ColdBox module is to create a server.json in my test-harness (similar to your www folder, I believe). Then I set the test-harness/box.json file to watch the root directory with the following commands:
package set reinitWatchDirectory=../
package set reinitWatchDelay=500
package set reinitWatchPaths=**.cfc
This can prolly be fixed easily by changing how we search for the server in the reinit command. The rest of the server commands in CommandBox have a name, directory (webroot), and serverConfigFile (server.json file) arg, but by default, don’t pass anything to the ServerService.resolveServerDetails() method, allowing it to exhaust all the mechanisms it has for finding the server.
The reinit command, for whatever reason, passes in the current working directory explicitly, which limits where it looks.
var serverInfo = serverService.getServerInfoByDiscovery( getCWD(), arguments.name );
I suppose that’s not quite, but I guess we just never noticed, since it works on most servers. I would welcome a simple pull here to basically stop passing the directory all together.
The open browser URLs will always favor SSL, if enabled. That said, the port key in the “server info” will always be the HTTP listener, so I’m not sure what you’ve got going on there. It’s possible you’re getting details of another server based on where you run the command.
@bdw429s I’m happy to take a stab at a PR. Are you suggesting I change the above line to this instead? var serverInfo = serverService.getServerInfoByDiscovery( name = arguments.name );
@bdw429s, I am glad I tested. The change to reinit.cfc doesn’t work. I still get “No server configurations found for… so have no clue what to reinit buddy!”
server start worked as expected. The “test-harness” was the web root.
calling fwreinit from the module root (one directory up from test-harness) did not work.
Maybe the fwreinit command should check for the server.json webroot key and use that to determine the path?
The reinit.cfc run method looked like this during my test:
/**
* @password The FWReinit password
* @name Name of the CommandBox server to reinit
* @showUrl Show the Url to reinit
**/
function run(
password = "1",
name = "",
showUrl = true
){
var serverInfo = serverService.getServerInfoByDiscovery( name = arguments.name );
if ( !structCount( serverInfo ) ) {
print.boldRedLine(
"No server configurations found for '#getCWD()#', so have no clue what to reinit buddy!"
);
} else {
var thisURL = "#serverInfo.host#:#serverInfo.port#/?fwreinit=#arguments.password#";
if ( arguments.showUrl ) {
print.greenLine( "Hitting... #thisURL#" );
}
http result="local.results" url="#thisURL#";
if ( findNoCase( "200", local.results.statusCode ) ) {
print.boldGreenLine( "App Reinited!" );
} else {
print
.redLine( "status code: #local.results.statusCode#" )
.redline( "error detail: " & local.results.errorDetail )
.line( trim( formatter.HTML2ANSI( local.results.filecontent ) ) );
}
}
}
Update:
The change works if you specify the name argument when calling fwreinit like this:
fwreinit name=mymodule
@bdw429s is there a way to automatically default the name to the name property value in the current working directory’s server.json?
I’m thinking we need to make the following change in reinit.cfc:
/**
* @password The FWReinit password
* @name Name of the CommandBox server to reinit
* @showUrl Show the Url to reinit
**/
function run(
password = "1",
name = "", // <-- should default to the CWD's server.json `name` attribute, if present.
showUrl = true
){
component aliases="fwreinit" {
// DI
property name="serverService" inject="ServerService";
property name="formatter" inject="formatter";
/**
* @password The FWReinit password
* @name Name of the CommandBox server to reinit, will default to the name listed in server.json file
* @showUrl Show the Url to reinit
**/
function run(
password = "1",
name = getDefaultServerName(),
showUrl = true
){
var serverInfo = serverService.getServerInfoByDiscovery( name = arguments.name );
if ( !structCount( serverInfo ) ) {
print.boldRedLine(
"No server configurations found for '#getCWD()#' and '#arguments.name#', so have no clue what to reinit buddy!"
);
} else {
var thisURL = "#serverInfo.host#:#serverInfo.port#/?fwreinit=#arguments.password#";
if ( arguments.showUrl ) {
print.greenLine( "Hitting... #thisURL#" );
}
http result="local.results" url="#thisURL#";
if ( findNoCase( "200", local.results.statusCode ) ) {
print.boldGreenLine( "App Reinited!" );
} else {
print
.redLine( "status code: #local.results.statusCode#" )
.redline( "error detail: " & local.results.errorDetail )
.line( trim( formatter.HTML2ANSI( local.results.filecontent ) ) );
}
}
}
/**
* Attempts to get the server name from the default server.json file
**/
private function getDefaultServerName() {
return serverService.getServerInfoByDiscovery( serverConfigFile = 'server.json' ).name;
}
}
I mean, the thing you’re describing is what the server service is supposed to be doing, lol. You shouldn’t have to call the server service to get the name so you can call the server service again with the name! I haven’t really looked to closely, but I assume there is something small/simple and silly different between what this command is doing and all the rest of the CommandBox server commands are doing. I would compare and see what’s different.
It’s highly probable I over-thought the above solution. However, the problem is that simply calling fwreinit in the project root when the web root is in a sub-folder, results in no server being found.
Therefore, I amended the run() method’s name argument to default to the name property in the server.json file. This alleviates the user having to type in fwreinit name=mymodule every time because it will automatically detect the name from server.json.
Another way to solve this problem would be ignore the changes I made in my previous post, and instead modify getServerInfoByDiscovery() so that webroot is properly calculated based on the server.json file. The following line doesn’t consider the actual web root of the config:
var webroot = arguments.directory is "" ? shell.pwd() : arguments.directory;
arguments.directory isn’t necessarally the webroot. Instead, there should be a server.json check to see if a manual webroot was specified and then update webroot accordingly.
And I think that’s the crux of the issue. That logic I linked to above is part of the resovleServerDetails() methed, which the reinit command is not using! I told you to compare what logic is in commands that work as expected in the CommandBox core. Here is an example of the server info command (which I assume works when run in the same folder as the server.json??) As you can see, it funnels through the resovleServerDetails() method, which has all the logic used when starting a server to resolve the actual server details based on the current directory, etc.