Server Start in 3.5 error says "Unrecognized option: --servlet-rest-mappings"

Hi Matt,

I’m running into a problem with starting a server in 3.5 :frowning: sorry so soon after the release!). Here’s the debug. It says that it doesn’t recognize “servlet-rest-mappings” as an option?

Dan

FusionReactor will be available at the URL http://127.0.0.1:55597

Server start command: C:\Users\djcar\Dropbox\sites\jre\bin\java.exe
-jar C:\Users\djcar.CommandBox\lib\runwar-3.4.10.jar
–background=true
–port 55408
–host 127.0.0.1
–debug=true
–stop-port 55595
–processname “yachts_intranet [adobe 10.0.22+301868]”
–log-dir “C:\Users\djcar.CommandBox/server/A10C28C640A8B29EB89C5CDEBE22EA0B-yachts_intranet/adobe-10.0.22.301868/logs”
–open-browser true
–open-url http://127.0.0.1:55408
–cfengine-name “adobe”
–server-name “yachts_intranet”
–tray-icon “C:\Users\djcar.CommandBox\cfml\system\config\server-icons\trayicon-cf10-32px.png”
–tray-config “C:\Users\djcar.CommandBox/server/A10C28C640A8B29EB89C5CDEBE22EA0B-yachts_intranet/trayOptions.json”
–servlet-rest-mappings “/rest/,/api/
–directoryindex “true”
–timeout 240
–jvm-args="-javaagent:“C:\Users\djcar.CommandBox/server/A10C28C640A8B29EB89C5CDEBE22EA0B-yachts_intranet/adobe-10.0.22.301868/fusionreactor/fusionreactor.jar=name=yachts_intranet,address=55597”;-Dfrlicense=C816A-C82DC-1A323-6857B-0AE5D;-Xmx512m;-Xms512m"
-war “C:\Users\djcar\Dropbox\sites\FalveySites\Yachts_Intranet”
–web-xml-path “C:\Users\djcar.CommandBox/server/A10C28C640A8B29EB89C5CDEBE22EA0B-yachts_intranet/adobe-10.0.22.301868/WEB-INF/web.xml”
–urlrewrite-enable false
The server for C:\Users\djcar\Dropbox\sites\FalveySites\Yachts_Intranet is starting on 127.0.0.1:55408…
org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: --servlet-rest-mappings
at org.apache.commons.cli.Parser.processOption(Parser.java:363)
at org.apache.commons.cli.Parser.parse(Parser.java:199)
at org.apache.commons.cli.Parser.parse(Parser.java:85)
at runwar.options.CommandLineHandler.parseArguments(CommandLineHandler.java:381)
at runwar.options.CommandLineHandler.parseArguments(CommandLineHandler.java:38)
at runwar.Server.startServer(Server.java:147)
at runwar.Start.main(Start.java:12)
USAGE: java -jar runwar.jar [-war] path/to/war [options]
org.apache.commons.cli.UnrecognizedOptionException Unrecognized option: --servlet-rest-mappings
CommandBox:Yachts_Intranet> ver
CommandBox 3.5.0+00600

Any thoughts?

Dan

...

Server start command: C:\Users\djcar\Dropbox\sites\jre\bin\java.exe
    -jar C:\Users\djcar\.CommandBox\lib\runwar-3.4.10.jar

This should be runwar-3.5.0.jar I believe, so maybe check if the update
to cmdbox 3.5 completed as expected?

-den

good spot. I’ll try it.

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.

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

Hi Brad,

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?

Dan

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.

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

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.

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

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:

https://github.com/Ortus-Solutions/commandbox/blob/development/src/java/cliloader/Util.java#L234-L239

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.

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

Oh np. CBS really has become one of my core tools.

Thanks!!!

Dan

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.

See the completed ticket here:

https://ortussolutions.atlassian.net/browse/COMMANDBOX-553

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