I’m poking around the source, the box archive, and the but I haven’t been able to find where I can force the railo server (tomcat?) to bind to a specific IP address or interface, instead of localhost.
I need to test some things that require network communication across multiple ‘instances’ and I was hoping to do this with just commandbox. Could anyone point me in the right direction?
As a side note, maybe I should create a ticket to add that argument to the ‘server start’? something like ‘server start bind=10.0.0.x’.
Disclaimer, I didn’t write the server start piece and I’m guess at how it works based on about 10 minutes of skimming the code just now I’d put in a ticket for the enhancement, but feel free to play around as well. You may be able to get it working by only modifying the start command and ServerService.
Server is up - http-port:56000 stop-port:56001 PID:1376
2014-11-19 23:58:47 INFO org.xnio.Xnio XNIO version 3.2.0.Final
2014-11-19 23:58:47 INFO org.xnio.nio.NioXnio XNIO NIO Implementation Version 3.2.0.Final
Waiting upto 35 seconds for 192.168.1.100:56000…
could not open browser to…http://192.168.1.100:56000… timeout…
Yes, I did a similar quick and unsuccessful test. I’d have to stop and trace everything through the Java classes. Hopefully Denny can respond on the ticket since he probably knows off the top of his head.
And to be clear, running the “upgrade” command will not update the jars. Right now there is no automated way to do that. What you have to do is remove the .CommandBox folder from your user directory, download the latest binary and re-execute. it will re-extract all the jars, etc fresh.
Yep! Re-installed using the latest download with 2.2.0 and binding to that host works, just need to update the cfc’s to pass the host argument along and it should work
Excellent news. I checked my lib folder and I also had an outdated jar which is probably why my test didn’t work either.
We’ll need to figure out an update mechanism to handler updates outside of the CFML directory. One of my ideas was to code the upgrade command to only work on dot releases, and bump a major version any time the libs got updated. Then, enhance the binary to auto-extract itself when it’s newer.
Good catch. Can you add a note for that on the ticket? Thanks for taking the time to work on this. Also please feel free to submit a pull request for the parts you get working.
Actually the stop socket is different than the httpport, so that should be 127. What happens when you try to stop? Can you try runwar alone and see if it works there? You should be able to basically use the same args displayed from commandbox.
Below is the out log, running runwar directly for starting & stopping. Trying to stop fails with an error message. Also when passing -stop, the help message it spits out specifies you can pass a -host argument.
Something to note is: the server can be stopped via the tray icon.
Again, I’m not a java developer so can someone please verify these changes? Pretty sure I got it correct, I built the classes and everything seemed to compile fine, but I couldn’t find how to create the .jar from the included built scripts in runwar…
Nevermind, I found the build target. Tested my compiled runwar-2.2.0.jar - stopping the server works as expected if you pass the -host param:
“C:\Program Files\Java\jre1.8.0_20\bin\java.exe” -jar “C:\Users\don.CommandBox\lib\runwar-2.2.0.jar” -stop --stop-port 56001 --background false --debug true -host x.x.x.x
Alright, I applied your changes Don, they're in runwar 2.2.1 if you want
to give it a spin and check.
The pull request was against a fork, so I had to grab the commit vs.
using that pull (which can be closed now if it's working).
Oh darn. Now I remember why it was supposed to be locked to localhost--
without a password as well, anyone can shut down the server by hitting
that port. The other thing I did remember, but wasn't too concerned
about, was that interfaces besides localhost can get into states that
won't let you "talk" to them, potentially starting servers without being
able to stop them. I think time would tell if that would be much of a
problem, but having the server stop when someone portscans it is. For
now we'll leave it be, but we need a password, the channel should be
over ssl probably, etc.. Thanks for your contribution, and do you have
any input on the password deal? I'm open so suggestions.
Alright, I applied your changes Don, they’re in runwar 2.2.1 if you want
to give it a spin and check.
I also updated CommandBox on it as well.
The pull request was against a fork, so I had to grab the commit vs.
using that pull (which can be closed now if it’s working).
Oh darn. Now I remember why it was supposed to be locked to localhost–
without a password as well, anyone can shut down the server by hitting
that port. The other thing I did remember, but wasn’t too concerned
about, was that interfaces besides localhost can get into states that
won’t let you “talk” to them, potentially starting servers without being
able to stop them. I think time would tell if that would be much of a
problem, but having the server stop when someone portscans it is. For
now we’ll leave it be, but we need a password, the channel should be
over ssl probably, etc… Thanks for your contribution, and do you have
any input on the password deal? I’m open so suggestions.
I don’t know if am very concerned with it, but maybe setting a default password is good. And maybe a way to change it on a per server level is also good.
With that in mind, I have a question, (As I have not had time to digest runwar just yet). Does undertow support SSL? This is a key component sometimes for local development.
I’d put in a ticket for the enhancement, but feel free to play around as well. You may be able to get it working by only modifying the start command and ServerService.