It has to do with the Tomcat version, you can downgrade the Tomcat version until this issue is resolved. Please also add a comment saying you are facing the issue and vote for the JIRA issue here: [DHIS2-7269] - Jira
More specifically, this error was identified for Tomcat 8.5.43 and 9.0.22 (released at the same time) - 8.5.42 and 9.0.21 work fine.
@Jay what tomcat version are you using? Please confirm if it is 8.5.46 (the latest) or 9.0.26 (latest) - if yes, then we know this is a permanent Tomcat change breaking compatibility with DHIS2 (and the DHIS2 core devs need to fix it).
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation. The default
SSLImplementation will depend on the presence of the APR/native
library and the useOpenSSL attribute of the
AprLifecycleListener.
Either JSSE or OpenSSL style configuration may be used regardless of
the SSLImplementation selected. JSSE style configuration is used below.
-->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
</SSLHostConfig>
</Connector>
-->
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443 with HTTP/2
This connector uses the APR/native implementation which always uses
OpenSSL for TLS.
Either JSSE or OpenSSL style configuration may be used. OpenSSL style
configuration is used below.
-->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="150" SSLEnabled="true" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig>
<Certificate certificateKeyFile="conf/localhost-rsa-key.pem"
certificateFile="conf/localhost-rsa-cert.pem"
certificateChainFile="conf/localhost-rsa-chain.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
</Engine>
I have just tested Tomcat 8.5.46 (the newest version), and the problem is still there - so it is obvious that this Icon error problem is a permanent issue with Tomcat 8.5.43 and later, as well as Tomcat 9.0.22 and later. Or in other words, DHIS2 is no longer fully compatible with newer versions of Tomcat 8.5.x and 9.0.x. There might be some configuration setting available that would bypass the problem, but in any case the issue is now a job for the relevant core dev team. @varl can you please investigate the issue - just run any DHIS2 instance under 8.5.43 or later, or 9.0.22 or later. Then go to e.g. Maintenance
NOTE re questions above: I am running localhost directly (no nginx or other load balancing software) and the server.xml is the default. I have tested with and without the setting added to Tomcat’s context.xml file, but that has no bearing on the problem (increasing Tomcat’s cache size seems to be required on Windows if you want full access to the icon library)
I’ve spent the day on this and tested these Tomcat versions:
Tomcat 8.5.34
Tomcat 8.5.46
Tomcat 9.0.26
All of these work properly on Linux, so I don’t think this is a problem with the DHIS2 core software specifically. I suspect it is the Java encoding in Windows that is tripping this up. Tomcat recently changed to falling back to the system default if it is not provided across all major tomcat channels (8.0.x, 8.5.x, and 9.0.x).
Could you please provide the output of:
java -XshowSettings:properties -version
I am specifically interested in the file.encoding property.
If that is set to windows-1252 (or anything except UTF-8/UTF8) then doing this in tomcat/bin/setenv.bat should do the trick:
set "JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF8"
Hope this helps and hearing back from you with the requested information.
@varl I think you are definitely on to something here - my output is below, and the file.encoding is codepage 1252 (the most common western codepage). I had not spotted that Tomcat change, but it would explain why the problem suddenly appeared with versions 8.5.43 and 9.0.22 - my default java codepage has been 1252 all along, but never caused problems because Tomcat was sort of “overlooking” the issue.
I even wonder if this might resolve another JIRA issue related to SQL View output not displaying “extended” characters correctly.
BINGO - there is no setenv.bat file in the tomcat/bin/ directory, but I created one with the
set “JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF8”
line as the only content.
I then upgraded again to 8.5.46, started tomcat, and
The nonsense icons under Maintenance is now gone, so setting the java file encoding to UTF8 did the trick.
The output of SQL views was not showing correctly (JIRA issue #4651 - over one year old!!), but this change to the codepage has resolved that too.
I have occasionally noted similar issues with a variety of XML/excel outputs from DHIS2, and I suspect this fix will resolve many of those issues too.
I have added the above fix to #4651, but can you please close the issue?
I would also suggest that this issue and its solution are added to the installation manual in a WARNING box (or something like that). 98% of all users are unlikely to be aware that their 64 bits Tomcat installation running on 64 bits window by default will be running an 8-bits codepage…
At least 2 birds with one stone - that’s good work, Viktor
@varl l’m having the same issue with Windows 10, Tomcat 9 combination. I also don’t have setenv.bat by default in bin folder. Unfortunately manually creating setenv.bat inside bin folder did not help me get rid of this error.
Hello everyone,
I have this same issue, and I tried the solution as suggested, but it didn’t work. I have Dhis 2.30 instance and I use Tomcat 9.0.21. Thanks.