Docker: java.lang.NoClassDefFoundError: sun.awt.X11FontManager

简介: Docker: java.lang.NoClassDefFoundError: sun.awt.X11FontManager

目录

问题现象

问题原因:

问题解决:

容器环境下

非容器环境下


 


问题现象

Dockerfile基础镜像从 java:8

更换为 adoptopenjdk/openjdk8-openj9:alpine-slim 后

登录页面的验证码无法加载,并报错

2021-08-24 01:30:25.763 ERROR 1 --- [or-http-epoll-4] reactor.netty.http.server.HttpServer     : [id: 0xf73ab911, L:/172.23.0.4:8081 - R:/10.0.159.222:52873] 
java.lang.NoClassDefFoundError: sun.awt.X11FontManager (initialization failure)
  at java.lang.J9VMInternals.initializationAlreadyFailed(Unknown Source) ~[na:1.8.0_302]
  at java.lang.Class.forNameImpl(Native Method) ~[na:1.8.0_302]
  at java.lang.Class.forName(Unknown Source) ~[na:1.8.0_302]
  at sun.font.FontManagerFactory$1.run(Unknown Source) ~[na:1.8.0_302]
  at java.security.AccessController.doPrivileged(Unknown Source) ~[na:1.8.0_302]
  at sun.font.FontManagerFactory.getInstance(Unknown Source) ~[na:1.8.0_302]
  at java.awt.Font.getFont2D(Unknown Source) ~[na:1.8.0_302]
  at java.awt.Font.access$000(Unknown Source) ~[na:1.8.0_302]
  at java.awt.Font$FontAccessImpl.getFont2D(Unknown Source) ~[na:1.8.0_302]
  at sun.font.FontUtilities.getFont2D(Unknown Source) ~[na:1.8.0_302]
  at com.google.code.kaptcha.text.impl.DefaultWordRenderer.renderWord(DefaultWordRenderer.java:66) ~[kaptcha-2.3.2.jar!/:2.3.2]
  at com.google.code.kaptcha.impl.DefaultKaptcha.createImage(DefaultKaptcha.java:43) ~[kaptcha-2.3.2.jar!/:2.3.2]
  at com.jiean.gateway.service.impl.ValidateCodeServiceImpl.createCapcha(ValidateCodeServiceImpl.java:61) ~[classes!/:na]
  at com.jiean.gateway.handler.ValidateCodeHandler.handle(ValidateCodeHandler.java:33) ~[classes!/:na]
  at 
  at java.lang.Thread.run(Unknown Source) [na:1.8.0_302]
Caused by: java.lang.UnsatisfiedLinkError: fontmanager (libfreetype.so.6: cannot open shared object file: No such file or directory)


问题原因:

这种一般是出现在 docker部署,且使用了精简版的基础镜像,有多精简呢?精简到把字体都阉割掉了,好狠…

如果你的项目有字体相关操作,比如导出 excel,验证码,就会报上述异常。

对于一个Java服务器来说经常要处理一些图形元素,例如地图的创建或者图形和图表等。这些API基本上总是需要运行一个X-server以便能使用AWT(Abstract Window Toolkit,抽象窗口工具集)。


问题解决:

容器环境下

换个东西全一点的镜像;

FROM java:8

在构建镜像时安装字体,dockerfile增加命令:

RUN yum install dejavu-sans-fonts fontconfig -y

如果 container已经启动,又不想换,那就直接进到 container,安装字体:

yum install dejavu-sans-fonts fontconfig -y


非容器环境下

从代码层面手工设置了 System.setProperty("java.awt.headless","true"); 解决问题。

@SpringBootApplication
public class EbootApplication {
   public static void main(String[] args) {
      System.setProperty("java.awt.headless", "true");
      SpringApplication.run(EbootApplication.class, args);
   }
}

什么是Headless mode?Headless模式是系统的一种配置模式。在该模式下,系统缺少了显示设备、键盘或鼠标。

一般是在程序开始激活headless模式,告诉程序,现在你要工作在Headless mode下,就不要指望硬件帮忙了,自力更生并依靠系统的计算能力模拟出这些特性来。


目录
相关文章
|
10月前
|
Java Docker 容器
|
4月前
|
监控 前端开发 Java
【技术开发】接口管理平台要用什么技术栈?推荐:Java+Vue3+Docker+MySQL
该文档介绍了基于Java后端和Vue3前端构建的管理系统的技术栈及功能模块,涵盖管理后台的访问、登录、首页概览、API接口管理、接口权限设置、接口监控、计费管理、账号管理、应用管理、数据库配置、站点配置及管理员个人设置等内容,并提供了访问地址及操作指南。
|
8月前
|
存储 Java Docker
使用Docker部署Java应用的最佳实践
使用Docker部署Java应用的最佳实践
|
7月前
|
jenkins 持续交付 开发工具
"引爆效率革命!Docker+Jenkins+GIT+Tomcat:解锁持续集成魔法,一键部署Java Web应用的梦幻之旅!"
【8月更文挑战第9天】随着软件开发复杂度的增加,自动化变得至关重要。本文通过实例展示如何结合Docker、Jenkins、Git与Tomcat建立高效的持续集成(CI)流程。Docker确保应用环境一致性;Jenkins自动化处理构建、测试和部署;Git管理源代码版本;Tomcat部署Web应用。在Jenkins中配置Git插件并设置项目,集成Docker构建Tomcat应用镜像并运行容器。此外,通过自动化测试、代码质量检查、环境隔离和日志监控确保CI流程顺畅,从而显著提高开发效率和软件质量。
111 3
|
8月前
|
Java Scala 流计算
实时计算 Flink版产品使用问题之Docker镜像中的Java路径和容器内的Java路径不一致,是什么导致的
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
8月前
|
存储 Java Docker
使用Docker部署Java应用的最佳实践
使用Docker部署Java应用的最佳实践
|
8月前
|
Java 持续交付 Docker
如何在Java中使用Docker
如何在Java中使用Docker
|
8月前
|
Java 持续交付 Docker
如何在Java中使用Docker
如何在Java中使用Docker
|
8月前
|
Ubuntu Linux Docker
Java演进问题之Alpine Linux创建更小的Docker镜像如何解决
Java演进问题之Alpine Linux创建更小的Docker镜像如何解决
|
9月前
|
监控 Java 数据安全/隐私保护
性能监控之 JMX 监控 Docker 容器中的 Java 应用
【6月更文挑战9天】性能监控之 JMX 监控 Docker 容器中的 Java 应用
728 1