http://coldfusion.com logo
Join Slack
Powered by
Hi, we are testing the commandbox-service-manager....
# box-products
b
Hi, we are testing the commandbox-service-manager. Is it possible to influence the "directory" parameter that is used in the startup command? I have tried setting it with this command 
server service update name=sm1apc directory="C:/software/web/profit-tasks"
And Ii have set the same value in the server.json file. But still in the windows event viewer the directory points to the 
/htdocs
folder
b
@birdy1980 I can't reproduce this. Can you provide specific steps? Here is what I tried
Copy code
mkdir servicewebroot --cd

mkdir www
touch www/index.cfm
echo "test" > www/index.cfm

server set web.webroot=www

server service create
server service start
Once I created the service, I confirmed the correct directory was being passed into the start command
Copy code
❯ server service info --verbose
which included this line
Copy code
set www4 AppParameters "server start name='www4' directory='C:/sandbox/servicewebroot/www/' serverConfigFile='C:\\sandbox\\servicewebroot\\www\\/server.json' --console --verbose --noSaveSettings --noOpenBrowser --noTrayEnable"
And the site serves the content from my 
www
folder
Now, I do see that the start command is looking in the www folder for the server.json. is that perhaps what you're seeing?
As far as your original question-- I'd recommend removing any extra services and forgetting any extra servers. Then I'd put the service name and web root in your server.json and just run the create command with no args in the directory of the server.json so it picks everything up.
The directory is simply the web root
b
The problem I have is that we put the server.json outside the webroot. We added a custom cf engine and the path to the file is relative to the server.json. If the workingdirectory is at the wwwroot that file cannot be resolved. I though it would be possible to adjust the starting directory of the service.
Specific steps to recreate the problem would be:
Copy code
mkdir servicewebroot --cd

// add a lucee-engine.zip to servicewebroot
server set app.cfengine="lucee-engine.zip"

mkdir www
touch www/index.cfm
echo "test" > www/index.cfm

server set web.webroot=www

server service create
server service start
This will result in an error that says that lucee-engine.zip is not a valid entry slug on forgebox. if you try to set the cfengine to "./lucee-engine.zip" the error says file or directory "./lucee-engine.zip" does not exist
b
@birdy1980 Ok, let's back up-- now you're introducing a separate, unrelated issue
Copy code
server set app.cfengine="lucee-engine.zip"
Where exactly is the 
lucee-engine.zip
file on disk?
I'm not sure a relative path will even work here.
I would expect you to need an absolute path
But only because the value there is basically passed to the endpoint service to resolve which endpoint will be used (forgebox, http, file, folder, etc) and I doubt the context of the folder the 
server.json
is in gets passed along like it would if you were to do something like
Copy code
install file.zip
from the CLI
And to be clear, this cfengine stuff is unrelated to how the service is getting created.
b
We put the lucee-engine.zip in the same folder as server.json. In the documentation it says that paths in the server.json file are relative to that file. For the cfengine parameter that does not seem de be the case,
b
@birdy1980 That's because it's not a path that the server deals with directly. It's just a random string containing an installation ID which the server tosses over to the package service and says, "_hey can you look at this and try to figure out what needs installed_". The package service just defaults to the shell's current working dir when it asks the endpoint service to see if the install ID is a relative file path. That said, I should be able to make it work by having the server bits pass along the info about where the 
server.json
lived (unless, of course, the 
cfengine
came from a CLI arg or a server default), but that will be in the next version.
I think you're officially the first person who ever tried using a relative file path for a cfengine install ID and had your 
server.json
out of the web root.
For now you'll need to either • use an absolute path • or account for the fact that the lookup is going to be relative to the current working dir of the shell for now and that it will change in a future version when I finally make it smarter
Now, that aside, I would like to get back to your original question about the service. I think there's a good chance I fixed your issue yesterday, but since I couldn't reproduce exactly what you had I'm not really sure. I was going to recommend you create the service with the specific path to the 
server.json
but we got sidetracked on the cfengine question.
Copy code
server service create serverConfigFile=path/to/server.json
b
Thanks for the info. I understand that the cfengine paramater is not a path, even if you start with 
file:./lucee-engine.zip
it's still an ID that is tried as a path relative to the working directory. We have moved the engine.zip to our s3 storage so the cfengine starts with 
https://
That works.
b
even if you start with 
file:./lucee-engine.zip
it's still an ID that is tried as a path relative to the working directory
To be clear (assuming 
foo.txt
exists)
Copy code
install foo.txt
is the same as
Copy code
install file:foo.txt
its just that the endpoint is explicit int he second one. So obviously they are going to work the same in both cases, which is to use the current working dir of the shell. But that is all fixed on the bleeding edge of CommandBox via COMMANDBOX-1492. At least, in my local testing last night. Please feel free to grab the snapshot build and help test for me.
Now can you confirm if the directory is still incorrect for the service creation-- we never really made it back to that. And while you may have only cared about it because you thought it affected the cfengine lookup, it's still incorrect.
3 Views
Open in Slack
PreviousNext
Powered by