Installation

Installation covers the server-side components that an IT person sets up once the basics are working. For installing the database, the application and the database connection, follow the step-by-step Install Guide instead.

Task	Page
Which file to download	Downloads
Install SQL Server Express, MySQL, MariaDB or Oracle	Install Database
Run the Commander4j installer (Full or Workstation)	Install Commander4j
Connect Commander4j to the database and create the tables	Setup4j
Log in for the first time	First Login
Move to a newer version	Upgrading

The sections below are only needed for hand-held scanners, ERP interfaces and barcode printers.

Install Java

The Windows and macOS installers include their own copy of Java, so a normal desktop installation needs nothing extra. You only need to install Java 25 yourself in two cases:

• The web component (the scanner web application) on the server that runs Apache Tomcat. Tomcat itself needs Java to run.
• The desktop application on Linux, because the Linux installer does not bundle Java.

In both cases install the JDK (not the smaller JRE). The Azul Zulu JDK 25 from https://www.azul.com/downloads/?package=jdk#zulu is recommended; on Windows choose the .msi installer and tick the option to set JAVA_HOME, which the Tomcat installer looks for.

Note that the web application should be installed on a nominated server machine and not on workstations.

Install Tomcat 11.x

Apache Tomcat 11 is required for the web component. Download it from the Apache Tomcat site. On Windows choose the 32-bit/64-bit Windows Service Installer so that Tomcat runs as a service and starts with the machine. The installer asks for the Java location: point it at the JDK you installed above.

Configure Tomcat / Web Application

The web component of Commander4j is a single file, c4j_commander4j_web.war, included with every release from version 12.75 onwards (it replaced the three separate web applications of earlier releases, which are listed below for sites that still run them). It contains the scanner pages and the REST API they use.

The servlet (.war) files shown below are intended to work on Zebra Mobile Computers which have the Zebra Enterprise Browser installed.

Servlet	Purpose	Environment	Notes
c4j_commander4j_web.war	Pallet Transactions, Quality Grading, Issue / Return	Any Mobile Browser	* Recommended from 12.75
c4j_web_react.war	Pallet Transactions	Any Mobile Browser	Earlier releases
c4j_web_WS.war	Quality — Product Grading	Any Mobile Browser	Earlier releases; only needed for Quality Control
c4j_web_Issue.war	Issue Pallets to Order & Location	Tablet Mobile Browser	Earlier releases; Issue/Return of Stock

Installing the web element of Commander4j is straightforward and requires copying files from the Commander4j install directory into the Tomcat directory:

• Stop the Apache Tomcat service if it is running.
• Copy the file chosen_servlet.war from the Commander4j directory into the WebApps subdirectory of the Tomcat installation directory.
• Start the Apache Tomcat service.
• You should then notice that the chosen_servlet directory has been created under WebApps.
• Update the list of hosts the web application can connect to by copying "Commander4j/xml/hosts/hosts.xml" into "Tomcat/WebApps/chosen_servlet/xml/hosts".
• Confirm this is working by opening the URL http://servername:8080/chosen_servlet/
• If you update the hosts.xml file for a servlet you will need to either restart Apache Tomcat or stop and start the servlet from the Apache Tomcat Manager.
• If you want to connect to a SQL Server database using Windows Integrated Authentication, copy the appropriate version of the auth DLL from the downloaded MS JDBC drivers (e.g. mssql-jdbc_auth-12.10.0.x64.dll) into the Java bin folder.

Optional: allow other web servers to call the REST API (CORS)

The scanner pages and the REST API are served from the same web application, so browsers need no special permission to use them. If pages served from another web server (a different host name or port) need to call the API from the browser, Tomcat must be told to allow cross-origin requests. Tomcat includes a filter for this. Add the following inside the <web-app> element of conf\web.xml in the Tomcat installation folder, then restart the Tomcat service:

<filter>
	<filter-name>CorsFilter</filter-name>
	<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
	<init-param>
		<param-name>cors.allowed.origins</param-name>
		<param-value>*</param-value>
	</init-param>
	<init-param>
		<param-name>cors.allowed.methods</param-name>
		<param-value>GET,POST,PUT,DELETE,HEAD,OPTIONS</param-value>
	</init-param>
	<init-param>
		<param-name>cors.allowed.headers</param-name>
		<param-value>Content-Type,X-Requested-With,Accept,Authorization,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</param-value>
	</init-param>
	<init-param>
		<param-name>cors.exposed.headers</param-name>
		<param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>
	</init-param>
</filter>
<filter-mapping>
	<filter-name>CorsFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

Two things to be aware of. Placing the filter in conf\web.xml applies it to every web application on that Tomcat, including the Tomcat manager, so only do this on a Tomcat dedicated to Commander4j. And because cors.allowed.origins is *, the filter does not pass the login cookie across origins (Tomcat's cors.support.credentials setting stays at its default of false); a page on another server can therefore only call API functions that do not need a logged-in session. To allow a logged-in session from another server, replace * with that server's exact origin, for example http://scanner-pages.example.local:8080, and add an init-param setting cors.support.credentials to true.

Create Commander4j Services

See Install Interface Services.

Install Local Middleware

The local middleware service handles the processing of inbound and outbound interface files between Commander4j and external systems such as an ERP. It runs as a background service on the Commander4j server machine and is configured via the Interface Admin screen within the application.

To install the interface service:

• Ensure Commander4j has been installed using the Full install option, which includes the service wrapper components.
• Open Commander4j, navigate to System > Interface Admin and verify that your interface definitions are configured correctly.
• Use the Assign Service function within the application to register the interface process as a Windows service (on Windows) or configure it as a startup process on Linux/macOS.
• Once registered, start the service and monitor the Interface Log to confirm that messages are being processed correctly.

If you are using Middleware4j to transform files before they reach Commander4j, install and configure Middleware4j separately — see the Middleware4j wiki page for details.

Install Print Queues

Commander4j uses two distinct methods for printing, and each requires a different type of print queue to be set up on the workstation or server.

Standard Reports (JasperReports)

Standard reports — such as pallet summaries, despatch notes and audit reports — are printed using JasperReports and sent to a regular operating system print queue, exactly as you would print a document from a word processor. Any printer visible to the operating system can be used. The report type is configured in the Modules screen.

On Windows, ensure the printer is installed and visible in the Windows Printers & Scanners settings. On Linux, CUPS-managed queues are supported.

Barcode Labels (ZPL)

Barcode labels — pallet labels, case labels and sample labels — are printed by sending raw ZPL (Zebra Printer Language) commands directly to a ZPL compatible printer. This bypasses the normal print driver rendering pipeline entirely, so the label must reach the printer untouched: either through a raw / pass-through print queue, or by Direct Print, where Commander4j sends the label straight to the printer's IP address and port with no operating system queue at all. Direct Print works on every platform and is described on Printer Queues.

• Windows — install the printer using the Seagull Scientific Generic Label driver, or configure a Generic / Text Only queue. Do not use a standard Zebra Windows driver, as this will re-interpret the ZPL rather than passing it through.
• macOS — a standard macOS printer queue will not work for ZPL output. On macOS 26 and earlier a raw queue can be created through the CUPS web interface, following the guidance at qz.io. From macOS 27 (Golden Gate) Apple has disabled the CUPS web interface, so use Direct Print instead.
• Linux — configure a CUPS raw queue pointing at the printer's IP address and port 9100.

If a label is accidentally sent to a standard print queue rather than a raw queue, the printer will output pages of ZPL text commands instead of a label. This is harmless but confirms the queue type needs to be changed.

To use Direct Print, define the printer in Label Printers with its IP address and port and Direct Print ticked, then tick Direct Print on the label's report module in Modules and make sure Group ID, Printer Type, Language and DPI agree on both. The printer then appears in the Print Queue drop-down of the label screens. See Printer Queues for the full walk-through.

See also: Zebra ZPL Label, Intermec IPL Label, Label Template Syntax.