I’m running into a problem with starting a server in 3.5 sorry so soon after the release!). Here’s the debug. It says that it doesn’t recognize “servlet-rest-mappings” as an option?
Yep, that’s def the wrong version of the runwar jar. Pls check the ~/.CommandBox/lib folder and make sure there’s not more than one version of the runwar jar in there. I did specific testing before releasing by installation CommandBox 3.4 and then upgrading it to 3.5 on Windows and it worked fine. If your upgrade to 3.5 left an old jar around or didn’t replace the jars please let us know more information about what version of CommandBox you were using before, the steps you took to upgrade, and the exact console output the first time you ran 3.5.
In fit of genius I did not use the upgrade command but downloaded the zip file and extracted it over the older version. When I ran it, it did say it was upgrading the .CommandBox installation.
Both runwar-3.4.10.jar and runwar-3.5.0.jar are in the .CommandBox\lib folder. There was also references to runwar-3.4.10.jar in the Server.json file which remained. I was hoping if I just overwrote those it would work fine but no luck and in fact it’s overwriting 3.5.0 with 3.4.10 in the server.json when I try to start it again. I stopped all the servers that were already running, renamed runwar-3.4.10.jar to get it out of the way then restarted Box and tried to start the server and viola. All set.
I’ll run the upgrade force again just in case but should I have stopped all the servers first before I upgraded?
What you did was fine. Just overwrite box.exe and you’re good. If you left servers running, that was most likely your mistake. Windows would have placed locks on the jar files and prevented them from being updated. I’m very surprised you didn’t get nasty errors about being unable to delete the files.
The upgrade command only works if the jars don’t need updated, which is basically never. Feel free to run it, but usually will just give you a URL to the download page and tell you to go do exactly what you did.
Oh, I forgot to address your mention of the fact that the old versions of runwar were in the servers.json file. There’s nothing wrong with that at all. The servers.json file is simply a snapshot of the last time the server was started. It has no bearing on future server starts.
Since two runwar jars existed, it was just a toss up as to what jar would get taken. Since Java was grabbing the older jar for whatever reason, that’s why it kept overwriting the file to have the old version again. There’s no way to “force” a version of runwar. We use whichever one Java picked up with the assumption that there will only be one.
So I did my 3.4 upgrade test again, but this time I left a server running on purpose. Sure enough, the upgrade to 3.5 appeared to complete, but in reality it left a number of old jars in the lib folder. I think the issue is from this bit of Java code that is in charge of deleting all old jars in the folder:
We’re catch any errors and the error output doesn’t seem to be tied to the console for some reason. I think we’ll look at updating that code to throw some sort of error if jar files are found as being locked since it basically means the upgrade probably won’t be correct.
Ok, I put in a fix for this that’s on the bleeding edge and will be part of the next CommandBox release.
If you attempt to update the jars in a CommandBox install but there are file system locks on them, you’ll get the following message and then the update will stop before it breaks anything.
*updating installed jars
Library path: C:\Users\Brad\.CommandBox\lib
Initializing libraries -- this will only happen once, and takes a few seconds...
CommandBox is having problems deleting your previous jars to complete the upgrade.
Please close all open consoles and stop all running servers before trying again.
sorry so soon after the release!). Here’s the debug. It says that it doesn’t recognize “servlet-rest-mappings” as an option?