一个只有WAR包和残缺源码的银行制卡发卡系统，本地跑不起来，原开发者失联。我花了36小时，从反编译到环境适配，最终让系统重新运转。
周末接到朋友紧急求助：某银行的一个制卡发卡系统突然“停摆”三天。原开发人员因车祸住院，手上只有线上运行的WAR包和一份25年9月份的旧版本源码（与线上差异较大）。银行IT部门催得紧，需要尽快恢复测试环境，以便后续二开和国产化适配。
朋友找到我：“你能不能把这个WAR包跑起来？我先看看效果。”
第一关：反编译与代码规整
拿到WAR包后，首先用JD-GUI反编译。好消息是没有混淆，类名、方法名都清晰可见。坏消息是：
所有中文注释变成乱码 （经排查是编译时的编码问题）
变量名被简化 ，lambda表达式全部被编译成匿名内部类
实体类字段顺序混乱 ，注解没有保留，多了好多builder辅助子类java文件
把乱码注释对照旧版本源码手动修正（旧版中文正常）。
重构lambda变形部分，恢复成可读的现代语法。
整理实体类，补充缺失的JPA注解默认值。
这一步花了将近一天。虽然繁琐，但为后续排查打下了基础。规整后的代码至少能让人看懂业务逻辑了。
第二关：环境搭建——WebLogic + Oracle的“版本地狱”
WebLogic 12c （老版本，对JDK1.8支持）
Oracle 11g （驱动用ojdbc8）
使用了 ESB企业服务总线 和 WebSocket ，地址有限制，11开头的，写死在配置文件中
我本地是WebLogic 12c + Oracle 19c + ojdbc8，直接部署报错：ClassNotFoundException: weblogic.jdbc.extensions.Driver。经排查是WebLogic容器中的oracle驱动和maven中的驱动版本不兼容，系统优先使用了WebLogic 12c中的oracle驱动。
折腾半天，最终在Docker里拉起一个WebLogic 12c + Oracle 11g的镜像，重新配置数据源。这一步走了不少弯路——不同版本的WebLogic对数据源配置文件的格式要求不一样，最后参考官方文档才调通。
第三关：ESB和WebSocket“假死”
启动应用时，控制台一直打印：
text Error creating bean with name 'esbClient': Failed to connect to ESB service at WebSocket connection to 'ws://...' failed: Connection refused
朋友一开始说：“那个ESB只有在点按钮时才用，启动时没关系。”但事实是，Spring容器初始化时就尝试创建ESB客户端Bean，连接不上直接导致启动失败。
解决方案是 修改配置文件 ，将ESB和WebSocket地址改为本地可模拟的假地址，并在代码里加入@Lazy注解延迟加载。为了不侵入代码，我通过重写配置文件的方式，把相关Bean的初始化改为懒加载。
这一步需要对Spring的Bean生命周期有较深理解。最终启动日志不再报错，应用成功部署，控制台输出Deployed "bank-card-system"。
第四关：数据库脚本与权限
系统自带的建表脚本是Oracle 11g格式，在当前11g环境运行时报错：ORA-00907: missing right parenthesis。原因是脚本中使用了过时的NUMBER(*,0)写法，需要改成NUMBER(38)。
经过上面四个关卡，系统终于在本地WebLogic上成功启动。我依次测试了登录、制卡申请、发卡记录查询三个核心流程，均可正常操作。虽然ESB和WebSocket因为没有真实环境无法联调，但系统主体功能已经跑通，可以进行后续的二开和界面调整。
1. 逆向老系统的标准流程
如果下次再遇到类似任务，我会按照这个顺序：
先跑原版WAR包 ，记录所有报错，不急着反编译。
环境版本必须对齐 ：WebLogic、Oracle、JDK版本一个都不能差。
配置外部化 ：把ESB、WebSocket等依赖地址全部抽到配置文件，用本地mock代替。
反编译推荐 JD-GUI 或 Bytecode Viewer ，配合native2ascii处理中文乱码。
Docker快速拉起老旧中间件环境，比本地安装省时80%。
这类“考古式”任务，技术难度不一定高，但极其繁琐。能沉下心来一个个排错，比会写新代码更重要。如果你也有类似的老系统需要“复活”，欢迎交流。
后记 ：目前系统已可本地运行，后续将根据银行需求进行功能改造和国产化适配。如果你也遇到只有WAR包、文档缺失、环境老旧的系统，可以私信我，帮你诊断。
全部评论