JBoss + WildFly 本地开发环境完全指南

其实原因很简单，就是项目需求……这两个月被 onboard 了一个新的老项目，原因大体是因为 InfoSec 发现了该项目里存在的一个安全隐患——通过 iframe 将 session id 传到了另一个 HTML 文件中，导致 session id 在 URL 上可见。这个项目本身也非常的老了——这个项目至少 17 年了，比 docker 的历史还久，因此之前修改了点内容，就得让后端的同时重新

GoldenaArcher

1490人浏览 · 2025-04-20 14:53:54

GoldenaArcher · 2025-04-20 14:53:54 发布

JBoss + WildFly 本地开发环境完全指南

本篇笔记主要实现在本地通过 docker 创建 JBoss 和 WildFly 服务器这一功能，基于红帽的禁制 EAP 版本的重新分发，所以我这里没办法放 JBoss EAP 的 zip 文件。WildFly 是免费开源的版本，可以在红帽官网找到

Github 地址为：<https://github.com/GoldenaArcher/jboss-docker-template>

前言 - 为什么要折腾 JBoss

其实原因很简单，就是项目需求……

这两个月被 onboard 了一个新的老项目，原因大体是因为 InfoSec 发现了该项目里存在的一个安全隐患——通过 iframe 将 session id 传到了另一个 HTML 文件中，导致 session id 在 URL 上可见。这个项目本身也非常的老了——这个项目至少 17 年了，比 docker 的历史还久，因此之前修改了点内容，就得让后端的同时重新 deploy 到我们的测试环境去做测试

这样一来麻烦，二来同时如果忙于其他的事情，那么就卡在了这里，因此从上个礼拜就在想怎么样可以把 docker 给搞起来，这样至少自己本地就可以修改+测试了

至于为什么要部署才能测试……原因也很简单，因为不是 SPA 啊，代码本身还是 JSF。我之前信誓旦旦的改完了 xhtml/html，本地跑起来页面显示完全没有问题，就是因为缺乏 environment context，需要放在 JSF 上打开。结果一部署，崩的彻彻底底的……

一次是因为 angular 没办法转译成功，N 次是因为 JSF 在编译后默默地出现了问题，又没有报错，只是渲染空屏。好不容易完成了 JSF 渲染的问题，现在又回到了 angular 转译失败的问题……

不得已，只能靠自己，想办法把 JBoss 服务器启起来，这样才能够比较流畅地开展下一步的 debug 过程

需要的工具

具体列表如下：

JBoss EAP 6.4.0
这个需要看一下自己项目的需求，从官网下载 EAP 需要 license
WildFly 8.2
如果没有 license 我推荐 WildFly
其实准确的说 JBoss EAP 6.4 对接的应该是 JBoss AS 7.5，不过我主要需要 fix 的地方在前端那里，后端的几近于无，WildFly 找起来容易一点
Java 8
Maven 3.6.3
Docker

这个版本的 JBoss EAP 和 WildFly 支持的应该还是 Java7，不过我们项目是用 Java8 跑的，我就下载 Java8 了，反正编译是没有错，能跑的

Docker Compose & Dockerfile

我这里不包括 zip 文件，下载就靠自己了……

Docker Compose

services:
  jboss:
    build:
      context: ./jboss
      dockerfile: Dockerfile
    container_name: jboss-eap
    ports:
      - "8080:8080"
      - "9990:9990"
      - "8787:8787"
    volumes:
      - ./deployments/jboss-mock:/opt/jboss/jboss-eap-6.4/standalone/deployments
    restart: unless-stopped

  wildfly:
    build:
      context: ./wildfly
      dockerfile: Dockerfile
    container_name: wildfly-8
    ports:
      - "8180:8080"
      - "9991:9990"
      - "8788:8787"
    volumes:
      - ./deployments/jboss-mock/webapp-1.0.0.war:/opt/wildfly/wildfly-8.2.0.Final/standalone/deployments/webapp-1.0.0.war
    restart: unless-stopped

这一步也是卡我卡的比较久的地方了……理论上来说 JBoss 和 WildFly 应该都是可以打包 ear 文件的，不过我至少折腾了两个小时跑 mvn clean install 和 docker compose --build -d ，最终还是没有能够正常的运行 ear 文件。反而是直接跑 war 就成功了……至少 JBoss 成功了

EAP 版本支持这个地方就可以看出来了，在 volumes 下面，JBoss 的配置是这样的: ./deployments/jboss-mock:/opt/jboss/jboss-eap-6.4/standalone/deployments ，换句话说，EAP 可以直接找到 deployments 下面的 war 文件，然后自动完成部署。不过 WildFly 缺乏对应的支持，它可以找到对应的 war 文件，没有办法顺利匹配到自己的部署路径里，所以需要手动写死路径： ./deployments/jboss-mock/webapp-1.0.0.war:/opt/wildfly/wildfly-8.2.0.Final/standalone/deployments/webapp-1.0.0.war，才能正常运行

还有一个问题就是，因为二者指向的 volume 是在一个路径，我本地上倒是发生过 JBoss deploy 了，但是 WildFly 没有。后面发现，可能是因为当 JBoss deploy 成功后，路径下面会出现一个 webapp-1.0.0.war.deployed 的文件，然后 WildFly 以为已经部署过了，就不会继续部署。暂时找到的解决方案是在要部署的文件夹中放一个 jboss-mock.ear.dodeploy 的空文件，目录如下：

这种情况下手动操作还是稍微烦了点，之后可能会写个 sh 脚本文件，搭配 mvn clean install 指令一起运行吧

运行后结果如下:

Dockerfile

二者从实现上基本上没有任何的差别，只有在 CMD 里面才有，运行的是不同的 sh

JBoss：

FROM openjdk:8-jdk

WORKDIR /opt/jboss

COPY jboss-eap-6.4.0.zip ./

RUN apt-get update && apt-get install -y unzip && \
unzip jboss-eap-6.4.0.zip && \
rm jboss-eap-6.4.0.zip

ENV JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8787"

EXPOSE 8080 9990 8787

CMD ["./jboss-eap-6.4/bin/standalone.sh", "-b", "0.0.0.0"]

WildFly：

FROM openjdk:8-jdk

WORKDIR /opt/wildfly

COPY wildfly-8.2.0.Final.zip ./

RUN apt-get update && apt-get install -y unzip && \
unzip wildfly-8.2.0.Final.zip && \
rm wildfly-8.2.0.Final.zip

ENV JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:8787"

EXPOSE 8080 9990 8787

CMD ["./wildfly-8.2.0.Final/bin/standalone.sh", "-b", "0.0.0.0"]

我另外加了个 debugger，就是 ENV JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:8787" 这里的内容，我在 VSCode 里倒是看到 debugger attach 了，不过我得下个礼拜和搞后端的同事一起看看，才能确定是不是能够正常的跑起来

辅助脚本

主要是启动和停止后清理的脚本

#!/bin/bash

set -e

echo "🔍 Checking if containers are already running..."
if docker ps -q --filter name=jboss | grep -q . || docker ps -q --filter name=wildfly | grep -q .; then
  echo "⚠️  Containers already running. Skipping start."
else
  echo "🚀 Starting JBoss and WildFly containers..."
  docker compose up --build -d
  echo "✅ Services started!"
  echo "   - JBoss:    http://localhost:8080"
  echo "   - WildFly:  http://localhost:8180"
fi

#!/bin/bash

set -e

echo "🛑 Stopping containers if they are running..."
docker-compose down || echo "⚠️  No containers to stop."

echo "🧽 Checking for images to delete..."
IMAGES=$(docker images -q --filter "reference=*jboss*" --filter "reference=*wildfly*" | sort -u)

if [ -z "$IMAGES" ]; then
  echo "✅ No matching images found to delete."
else
  echo "🗑️  Removing matching images..."
  docker rmi $IMAGES -f
  echo "✅ Images deleted."
fi

不用也没啥差别，就是要 docker compose --build 和 docker compose down 加上用 docker rmi，写个辅助环境稍微方便点

Java 项目结构

这里大体贴一个结构，pom 文件具体的就不放了，具体的内容在 github 上，这个本身就是一个 empty boilerplate，目前来说里面没内容的

debugger

这里就是 vscode 的配置了：

{
  "version": "0.2.0",
  "configurations":
    [
      {
        "type": "java",
        "name": "Attach to JBoss (8787)",
        "request": "attach",
        "hostName": "localhost",
        "port": 8787,
        "projectName": "jboss-mock",
        "sourcePaths":
          [
            "${workspaceFolder}/jboss-mock/webapp/src/main/java",
            "${workspaceFolder}/jboss-mock/ejb/src/main/java",
          ],
      },
      {
        "type": "java",
        "name": "Attach to WildFly (8788)",
        "request": "attach",
        "hostName": "localhost",
        "port": 8788,
        "projectName": "jboss-mock",
        "sourcePaths":
          [
            "${workspaceFolder}/jboss-mock/webapp/src/main/java",
            "${workspaceFolder}/jboss-mock/ejb/src/main/java",
          ],
      },
    ],
}