简介：本资源为 Drools 规则引擎 7.48.0 Final 正式发行版完整分发包，面向 Java 开发者、企业级规则系统设计人员及中间件集成工程师，适用于业务规则动态化管理、复杂决策逻辑解耦、可配置审批流与风控策略落地等典型场景。压缩包为标准 ZIP 格式，体积 64.01MB，虽未提供具体文件清单，但依据 Drools 官方 distribution 惯例，内含核心 JAR 库（如 drools-core、kie-api）、预编译示例工程、规则调试工具（Drools Workbench 相关脚手架）、文档（HTML/ASCII Doc 格式）及 Maven 依赖描述文件，便于开箱即用与本地集成验证。目前已有 309 人学习下载，适合需快速部署稳定版本、研究规则语法演进、比对 7.x 系列 API 变更或搭建本地规则测试环境的中高级开发者。
1. Drools 7.48.0.Final 安装不是“解压即用”：JDK 11 是硬门槛，Maven 3.6+ 是隐形守门员
你兴冲冲下载完drools-distribution-7.48.0.Final.zip，双击解压、进bin/目录敲./kieserver.sh start—— 结果报错UnsupportedClassVersionError: org/kie/api/KieServices has been compiled by a more recent version of the Java Runtime？别急，这不是 Drools 报错，是 JDK 在给你亮红灯。Drools 7.48.0.Final 是 Drools 7.x 系列中最后一个明确要求 JDK 11+ 的稳定 Final 版本（后续 7.49+ 开始逐步向 JDK 17 迁移），它彻底放弃了对 JDK 8 的兼容。我见过太多人卡在这一步：本地 JDK 8 环境跑着老项目，顺手想试下新 Drools，结果连kie-api的 class 都加载失败——不是 Drools 不行，是你 JVM 太老。这套环境不是给“试试看”的人准备的，而是给正在落地规则引擎、需要稳定 KIE Server + Workbench 组合、且已规划好 JDK 升级路径的团队用的。它不轻量，但够扎实；不时髦，但少玄学。如果你还在用 Spring Boot 2.3+ 或 WildFly 26+ 做底座，那 7.48.0.Final 反而是当前最省心的选型——它和这些中间件的依赖冲突最少，社区补丁最全。下面我们就从“装什么”开始，一砖一瓦垒出能跑通规则编译、部署、执行的完整 Drools 7.48 环境。
2. 环境准备与核心组件定位：先看清 ZIP 包里到底有什么
drools-distribution-7.48.0.Final.zip不是单个可执行 jar，而是一套开箱即用但需手动组装的工具集。它不像 Spring Boot 那样一个 jar 启动全部服务，而是把 KIE Server、Workbench、示例规则工程、文档、脚本全打包进来，交由你按需取用。理解每个子目录的用途，是避免后续“找不到配置文件”“启动报 NoClassDefFound”这类低级翻车的第一步。
2.1 解压后目录结构解析：哪些必须动，哪些可以删
解压后你会看到如下关键目录（路径以$DROOLS_HOME表示）：
| 目录 | 作用 | 是否必须 | 备注 |
|---|---|---|---|
bin/ | 启动/停止脚本（kieserver.sh/bat,workbench.sh/bat） | ✅ 必须 | Linux/macOS 用.sh，Windows 用.bat；脚本内硬编码了JAVA_HOME和JBOSS_HOME路径，需提前配置 |
business-central/ | Workbench（Web 控制台）WAR 包及嵌入式 WildFly 配置 | ✅ 必须（若需图形化管理） | business-central.war是核心，standalone/configuration/standalone.xml是关键配置文件 |
kie-server/ | KIE Server（规则执行服务）WAR 包及独立启动配置 | ✅ 必须（若需 REST API 调用规则） | kie-server.war是服务主体，standalone/configuration/standalone.xml同样需调参 |
samples/ | 官方示例工程（Maven 结构） | ⚠️ 推荐保留 | helloworld,loan-validation等 demo 是验证环境是否正常的黄金标准，别急着删 |
docs/ | PDF 格式官方文档（含 Installation Guide, Developer Guide） | ⚠️ 推荐保留 | InstallationGuide.pdf第 3 章详细说明了各组件端口、内存参数、安全配置，比官网 Wiki 更准 |
lib/ | 公共依赖 JAR（如kie-api-7.48.0.Final.jar） | ✅ 必须 | 所有 WAR 包都依赖此目录下的基础类库，不可删除或替换 |
提示：
drools-distribution-7.48.0.Final.zip不包含 JDK、Maven、WildFly 运行时。它假设你已准备好 JDK 11+ 和 Maven 3.6+（用于编译 sample），并会将 KIE Server / Workbench 部署到你指定的 WildFly（或内置轻量版）。不要试图用 Tomcat 运行kie-server.war——它强依赖 WildFly 的 Weld（CDI）、Infinispan（缓存）、PicketBox（安全）等模块，Tomcat 无法满足。
2.2 JDK 11 验证与环境变量固化：别让java -version欺骗你
Drools 7.48.0.Final 编译目标字节码版本为55.0（对应 JDK 11），任何低于此版本的 JVM 都会直接抛UnsupportedClassVersionError。但很多人java -version显示11.0.20，却仍启动失败——原因往往是JAVA_HOME指向了旧版本，而PATH里混进了另一个 JDK 的bin。
执行以下命令，三重验证你的 JDK 11 是否真正生效：
# 1. 查看当前 shell 的 JAVA_HOME（必须指向 JDK 11 根目录） echo $JAVA_HOME # 2. 查看 java 命令实际路径（确认没被 PATH 里的其他 java 覆盖） which java ls -la $(which java) # 3. 强制用 JAVA_HOME 下的 java 执行版本检查（绕过 PATH 干扰） $JAVA_HOME/bin/java -version输出必须为类似：
openjdk version "11.0.20" 2023-07-18 OpenJDK Runtime Environment Temurin-11.0.20+8 (build 11.0.20+8) OpenJDK 64-Bit Server VM Temurin-11.0.20+8 (build 11.0.20+8, mixed mode)注意：
JAVA_HOME不能指向 JRE 目录（如/usr/lib/jvm/java-11-openjdk-amd64/jre），必须指向 JDK 根目录（如/usr/lib/jvm/java-11-openjdk-amd64）。否则kieserver.sh会因找不到tools.jar（虽 JDK 11 已移除，但脚本逻辑仍校验）而静默失败。
2.3 Maven 3.6+ 与本地仓库一致性：sample 编译失败的元凶
samples/下的 demo 工程（如loan-validation）是 Maven 项目，其pom.xml中drools.version固定为7.48.0.Final，且依赖org.kie:kie-maven-plugin:7.48.0.Final。这个插件负责在编译时将.drl规则文件编译为KieModule。如果本地 Maven 仓库（默认~/.m2/repository）中存在旧版kie-maven-plugin（如 7.45.0），Maven 可能错误复用，导致编译生成的KieModule元数据不兼容 7.48 Server。
解决方案：强制清理并重装
# 删除本地仓库中所有 drools/kie 相关缓存（避免版本污染） rm -rf ~/.m2/repository/org/drools rm -rf ~/.m2/repository/org/kie # 清理 Maven 自身插件缓存（关键！） rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin rm -rf ~/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin # 验证 Maven 版本（必须 >= 3.6.0） mvn -v # 输出应包含：Apache Maven 3.6.3 或更高版本常见做法是：在
samples/loan-validation目录下执行mvn clean install -DskipTests，观察日志中是否出现Compiling DRL files using kie-maven-plugin。若卡在Downloading from central: https://repo.maven.apache.org/maven2/org/kie/kie-maven-plugin/7.48.0.Final/kie-maven-plugin-7.48.0.Final.pom，说明网络或仓库配置有问题，需检查~/.m2/settings.xml中的 mirror 或 proxy 设置（注意：此处不涉及任何代理工具，仅指企业内网 Nexus 配置）。
3. KIE Server 独立部署：从 WAR 包到可调用的 REST 接口
KIE Server 是 Drools 的核心执行引擎，提供 REST/Java API 让外部系统触发规则计算。drools-distribution-7.48.0.Final.zip提供了两种部署方式：嵌入式 WildFly（推荐新手）和外置 WildFly（推荐生产）。我们以嵌入式方式为例，因为它完全由 ZIP 包内脚本控制，路径、端口、内存参数全部固化，避免外置环境带来的变量干扰。
3.1 启动嵌入式 KIE Server：修改standalone.xml是必经之路
进入$DROOLS_HOME/kie-server/standalone/configuration/，打开standalone.xml。这是 WildFly 的主配置文件，KIE Server 的行为全由它定义。你需要修改三处关键节点：
修改 1：绑定地址与端口（避免端口冲突）
<!-- 找到 <interfaces> 节点，确保 management 和 public 接口绑定到 0.0.0.0 --> <interface name="management"> <inet-address value="0.0.0.0"/> </interface> <interface name="public"> <inet-address value="0.0.0.0"/> </interface> <!-- 找到 <socket-binding-group>，修改 http 端口（默认 8080，若被占用可改为 8180） --> <socket-binding name="http" port="${jboss.http.port:8180}"/> <socket-binding name="https" port="${jboss.https.port:8443}"/> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/> <socket-binding name="management-http" port="${jboss.management.http.port:9990}"/>修改 2：配置 KIE Server 安全域（启用 Basic Auth）
<!-- 在 <security-realms> 节点内添加 KIE Server 专用 realm --> <security-realm name="ApplicationRealm"> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/> </authorization> </security-realm>逻辑说明：Drools 7.48 默认启用 Basic 认证，
application-users.properties存放用户名密码（明文 Base64），application-roles.properties定义用户角色（如kie-server=kie-server,rest-all）。这是为了防止未授权访问规则服务，生产环境绝不可关闭。
修改 3：设置 JVM 内存与 GC 参数（避免 OOM）
<!-- 找到 <jvm> 节点（通常在 <server> 根节点下），添加或修改 --> <jvm name="default"> <heap size="1024m" max-size="2048m"/> <permgen size="256m" max-size="512m"/> <jvm-options> <option value="-XX:+UseG1GC"/> <option value="-XX:MaxGCPauseMillis=200"/> <option value="-Djava.net.preferIPv4Stack=true"/> <option value="-Djboss.modules.system.pkgs=org.jboss.byteman"/> </jvm-options> </jvm>参数说明：
heap max-size="2048m"是底线，KIE Server 加载多个 KieContainer 时内存消耗极大；UseG1GC是 JDK 11 推荐的垃圾收集器；preferIPv4Stack解决 Linux 下 IPv6 DNS 解析超时问题。
3.2 启动与日志诊断：kieserver.sh脚本的隐藏逻辑
执行启动命令前，确保$DROOLS_HOME已导出为环境变量：
export DROOLS_HOME=/path/to/drools-distribution-7.48.0.Final $DROOLS_HOME/kie-server/bin/kieserver.sh start该脚本实际执行流程为：
- 检查
JAVA_HOME是否有效（否则退出） - 设置
JBOSS_HOME=$DROOLS_HOME/kie-server - 调用
$JBOSS_HOME/bin/standalone.sh -c standalone.xml -b 0.0.0.0 -bmanagement 0.0.0.0 - 将日志输出重定向到
$JBOSS_HOME/standalone/log/server.log
关键日志判断点（打开server.log搜索）：
INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 18.0.1.Final (WildFly Core 10.0.3.Final)→ WildFly 启动成功INFO [org.kie.server.remote.rest.KieServerRestImpl] (default task-1) KieServer is up and running→ KIE Server 初始化完成INFO [org.kie.server.services.impl.KieServerImpl] (default task-1) Server 'default-kieserver' started successfully→ 默认容器启动成功
注意：首次启动会自动创建
kie-server用户（密码为kieserver1!），并写入application-users.properties。该密码可在server.log中搜索Added user找到，务必首次启动后立即修改。
3.3 验证 REST API 可用性：curl 是最可靠的探针
KIE Server 启动后，用 curl 测试基础健康接口：
# 1. 检查服务器状态（无需认证） curl -X GET "http://localhost:8180/kie-server/services/rest/server" # 2. 获取可用容器列表（需 Basic Auth） curl -X GET "http://localhost:8180/kie-server/services/rest/server/containers" \ -H "Accept: application/json" \ -u 'kieserver:kieserver1!' # 3. 创建一个空容器（测试部署能力） curl -X POST "http://localhost:8180/kie-server/services/rest/server/containers/mycontainer" \ -H "Content-Type: application/json" \ -d '{ "container-id" : "mycontainer", "release-id" : { "group-id" : "org.acme", "artifact-id" : "test", "version" : "1.0.0" } }' \ -u 'kieserver:kieserver1!'预期响应：步骤 1 返回
{"type":"SUCCESS","msg":"Kie Server Info"}；步骤 2 返回{"type":"SUCCESS","result":{"kie-containers":[]}}；步骤 3 返回{"type":"SUCCESS","msg":"Container mycontainer successfully created with release id org.acme:test:1.0.0"}。若返回 401，检查用户名密码；若返回 404，确认 WAR 包是否正确部署（$DROOLS_HOME/kie-server/standalone/deployments/kie-server.war.deployed文件存在）。
4. Workbench 图形化控制台部署：规则开发者的 IDE 替代方案
Workbench（现称 Business Central）是 Drools 的 Web IDE，提供规则编辑、版本管理、KIE Server 集成、流程建模等能力。它比纯 REST API 更适合规则分析师和业务人员协作。drools-distribution-7.48.0.Final.zip中的business-central.war是开箱即用的，但需注意其与 KIE Server 的双向集成配置。
4.1 部署 Workbench 到独立 WildFly 实例：避免端口与内存冲突
Workbench 和 KIE Server不能共用同一个 WildFly 实例。原因有二：一是两者 WAR 包都依赖大量同名库（如jbpm-workitems-7.48.0.Final.jar），类加载冲突；二是 Workbench 内置 H2 数据库，与 KIE Server 的 Infinispan 缓存争抢线程资源。因此，必须为 Workbench 单独准备一个 WildFly。
操作步骤：
- 下载 WildFly 26.1.0.Final（与 Drools 7.48 兼容性最佳）：
wget https://github.com/wildfly/wildfly/releases/download/26.1.0.Final/wildfly-26.1.0.Final.zip - 解压到
$WILDFLY_WORKBENCH，复制$DROOLS_HOME/business-central/business-central.war到$WILDFLY_WORKBENCH/standalone/deployments/ - 修改
$WILDFLY_WORKBENCH/standalone/configuration/standalone.xml：<socket-binding name="http" port="8080"/>（KIE Server 用 8180，Workbench 用 8080）<jvm heap size="2048m" max-size="4096m"/>（Workbench 内存需求更高）
4.2 配置 Workbench 连接 KIE Server：standalone.xml中的kie-server子系统
Workbench 需要知道 KIE Server 的地址才能推送规则包。在$WILDFLY_WORKBENCH/standalone/configuration/standalone.xml中，找到<subsystem xmlns="urn:jboss:domain:ee:4.0">节点，在其内部添加：
<subsystem xmlns="urn:jboss:domain:kie-server:2.0"> <configuration> <property name="org.kie.server.location" value="http://localhost:8180/kie-server/services/rest/server"/> <property name="org.kie.server.controller" value="http://localhost:8080/business-central/rest/controller"/> <property name="org.kie.server.controller.user" value="admin"/> <property name="org.kie.server.controller.pwd" value="admin"/> <property name="org.kie.server.id" value="workbench-kieserver"/> </configuration> </subsystem>逻辑说明：
org.kie.server.location是 KIE Server 的 REST 地址；org.kie.server.controller是 Workbench 自身的 Controller 地址（用于接收 KIE Server 的心跳）；admin/admin是 Workbench 的默认管理员账号（首次启动后需修改）。
4.3 启动 Workbench 并完成首次登录：初始化数据库与用户
启动 Workbench：
$WILDFLY_WORKBENCH/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0首次启动会自动初始化 H2 数据库，并创建默认用户：
- URL：
http://localhost:8080/business-central - 用户名：
admin - 密码：
admin
登录后，进入Admin Perspective → Servers，点击Add Server，填写：
- Server ID：
my-kieserver - Location：
http://localhost:8180/kie-server/services/rest/server - User：
kieserver - Password：
kieserver1!
点击 Save，Workbench 会尝试连接 KIE Server 并拉取容器列表。若显示Connected，说明双向集成成功。
避坑：若页面提示
Connection failed，检查server.log中是否有Failed to connect to controller。常见原因是 KIE Server 的standalone.xml中未开启 Controller 模式（需在<subsystem xmlns="urn:jboss:domain:kie-server:2.0">下添加<controller enabled="true"/>）。
5. 常见问题排查：那些让你重启三次仍失败的“经典翻车现场”
安装 Drools 7.48.0.Final 最耗时间的环节，往往不是配置本身，而是某些看似无关的细节引发的连锁故障。以下是我在某高校规则引擎教学平台部署中，记录的 5 条血泪经验，每一条都对应一个真实报错和可复现的解决路径。
5.1 现象：kieserver.sh start后进程秒退，server.log为空
原因：kieserver.sh脚本中JBOSS_HOME路径拼接错误，或$DROOLS_HOME末尾带/导致路径重复（如$DROOLS_HOME=/opt/drools/，脚本内写JBOSS_HOME=$DROOLS_HOME/kie-server，最终变成/opt/drools//kie-server）。Linux 下双斜杠会被忽略，但某些 Shell 会报错退出。
解决：在kieserver.sh开头添加调试语句echo "JBOSS_HOME=$JBOSS_HOME"，确认路径正确；或手动执行sh -x $DROOLS_HOME/kie-server/bin/kieserver.sh start查看实际执行命令。
5.2 现象：Workbench 登录后，Projects 页面空白，Console 报GET http://localhost:8080/business-central/rest/project 404
原因：WildFly 26 默认禁用了undertow的servlet子系统中的default-host，导致business-central.war的 Servlet 映射失效。
解决：在$WILDFLY_WORKBENCH/standalone/configuration/standalone.xml中，找到<subsystem xmlns="urn:jboss:domain:undertow:12.0">，确保<host name="default-host" ...>节点存在，且<location name="/" handler="welcome-content"/>未被注释。
5.3 现象：mvn clean install编译samples/loan-validation时，报错Could not resolve dependencies for project org.drools:loan-validation:jar:7.48.0.Final: Could not find artifact org.kie:kie-maven-plugin:jar:7.48.0.Final
原因：Maven 本地仓库中org/kie/kie-maven-plugin/7.48.0.Final/目录下只有kie-maven-plugin-7.48.0.Final.pom，缺少jar文件。这是因为kie-maven-plugin是 Maven 插件，其jar文件需从maven-metadata.xml中的plugins仓库下载，而非central。
解决：在~/.m2/settings.xml的<profiles>中添加：
<profile> <id>kie-plugins</id> <repositories> <repository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>https://repository.jboss.org/nexus/content/groups/public/</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>false</enabled></snapshots> </repository> </repositories> </profile>然后执行mvn clean install -Pkie-plugins。
5.4 现象：KIE Server 启动后，调用POST /containers/{id}创建容器，返回500 Internal Server Error，日志中出现java.lang.NoClassDefFoundError: org/infinispan/manager/EmbeddedCacheManager
原因：kie-server.war依赖的infinispan-embedded-10.1.8.Final.jar与 WildFly 26 自带的infinispan-core-12.1.7.Final.jar版本冲突，类加载器优先加载了旧版。
解决：在$DROOLS_HOME/kie-server/standalone/deployments/kie-server.war/WEB-INF/jboss-deployment-structure.xml中，添加<exclusions>排除 WildFly 提供的冲突模块：
<jboss-deployment-structure> <deployment> <exclusions> <module name="org.infinispan" /> <module name="org.infinispan.commons" /> </exclusions> </deployment> </jboss-deployment-structure>5.5 现象：Workbench 中新建规则项目，保存后提示Repository not found，Git 仓库未初始化
原因：Workbench 默认使用内置 Git（org.uberfire.java.nio.fs.jgit.JGitFileSystemProvider），但首次启动时未生成~/.business-central/git/目录，或该目录权限不足（如 root 创建，当前用户无写入权）。
解决：停止 Workbench，执行mkdir -p ~/.business-central/git && chown $USER:$USER ~/.business-central/git，再启动。
6. 验证环境跑通：用loan-validation示例走通“编写-编译-部署-执行”全链路
装完所有组件，最怕的就是“看起来都绿了，但真写条规则就挂”。我习惯用samples/loan-validation这个官方示例做终极验证——它结构清晰（单个.drl文件 + Java Fact 类），不依赖外部 DB，且规则逻辑简单（根据收入、信用分决定贷款额度），能快速暴露环境链路上的任一断点。下面带你从零开始，走一遍完整的规则生命周期。
6.1 编译并安装示例工程：生成可部署的 KJAR
进入$DROOLS_HOME/samples/loan-validation目录，执行：
mvn clean install -DskipTests成功后，会在target/下生成loan-validation-7.48.0.Final-kjar.jar（注意后缀是kjar，不是jar）。这是 KIE Server 可识别的特殊格式，内含META-INF/kmodule.xml和编译后的规则字节码。
关键检查点：打开
target/loan-validation-7.48.0.Final-kjar.jar，用jar -tf查看内容，必须包含：
META-INF/kmodule.xml（定义 KieBase/KieSession）org/drools/examples/loanvalidation/LoanApplication.classorg/drools/examples/loanvalidation/LoanApproval.classsrc/main/resources/org/drools/examples/loanvalidation/LoanValidation.drl（源规则文件）
若缺失kmodule.xml，说明kie-maven-plugin未生效，需回看第 5.3 条排查。
6.2 部署 KJAR 到 KIE Server：两种方式任选其一
方式一：通过 REST API（推荐，自动化友好）
curl -X PUT "http://localhost:8180/kie-server/services/rest/server/containers/loan-validation" \ -H "Content-Type: application/json" \ -d '{ "container-id" : "loan-validation", "release-id" : { "group-id" : "org.drools", "artifact-id" : "loan-validation", "version" : "7.48.0.Final" }, "resolved-release-id" : { "group-id" : "org.drools", "artifact-id" : "loan-validation", "version" : "7.48.0.Final" } }' \ -u 'kieserver:kieserver1!'方式二：通过 Workbench UI（适合调试）
- 登录 Workbench → Authoring → Project Authoring
- 点击右上角Project → Import Project，选择本地
target/loan-validation-7.48.0.Final-kjar.jar - 导入后，点击Deploy按钮，选择
loan-validation容器，点击OK
验证部署成功：访问
http://localhost:8180/kie-server/services/rest/server/containers/loan-validation，返回{"type":"SUCCESS","result":{"container-id":"loan-validation",...}}即可。
6.3 构造 Fact 对象并执行规则：用 curl 模拟真实业务请求
loan-validation规则逻辑是：
- 若
income > 50000 && creditScore > 700，则approval.setApproved(true)，approval.setAmount(10000) - 否则
approval.setApproved(false)
构造 JSON 请求体：
{ "lookup": "loan-validation", "commands": [ { "insert": { "object": { "org.drools.examples.loanvalidation.LoanApplication": { "income": 60000, "creditScore": 750 } }, "out-identifier": "application" } }, { "insert": { "object": { "org.drools.examples.loanvalidation.LoanApproval": { "approved": false, "amount": 0 } }, "out-identifier": "approval" } }, { "fire-all-rules": {} } ] }发送执行请求：
curl -X POST "http://localhost:8180/kie-server/services/rest/server/containers/loan-validation" \ -H "Content-Type: application/json" \ -d @request.json \ -u 'kieserver:kieserver1!'预期响应：
"execution-results":{"results":[{"value":{"org.drools.examples.loanvalidation.LoanApproval":{"approved":true,"amount":10000}}}]}
若approved:false，检查income或creditScore是否低于阈值；若返回400 Bad Request，检查 JSON 格式或out-identifier是否拼写错误。
6.4 进阶验证：修改规则并热更新，不重启服务
这才是 Drools 的核心价值。在 Workbench 中：
- 进入
loan-validation项目 →src/main/resources/org/drools/examples/loanvalidation/LoanValidation.drl - 将
income > 50000改为income > 40000，保存 - 点击Build & Deploy（注意不是 Deploy，是 Build & Deploy）
- 再次用 curl 发送相同请求，传入
income:45000, creditScore:750，应返回approved:true
技术原理：Workbench 的 Build & Deploy 会触发
kie-maven-plugin重新编译.drl，生成新版本 KJAR（如7.48.0.Final-2），并通知 KIE Server 加载新容器。整个过程无需重启 WildFly，规则变更秒级生效。
从那以后我每次搭建 Drools 环境，都强制走一遍loan-validation全链路：从mvn install生成 KJAR，到 REST 部署，再到 curl 执行，最后热更新验证。这 4 步像一道过滤网，能筛掉 90% 的配置疏漏——JDK 版本不对、Maven 插件失效、KIE Server 容器未注册、Workbench 与 Server 连接中断，全在这一串命令里暴露无遗。它不炫技，但足够诚实。希望帮到你。
本文还有配套的精品资源，点击获取
