简介《精通EJB源代码 第二版》是一本面向Java中高级开发者的企业级开发实战指南聚焦EJB 3.x核心机制与工程落地帮助读者突破分布式事务、容器服务集成、JPA持久化及Web服务协同等企业应用难点。资源包共279个文件含79个Java源码涵盖Session Bean、MDB、Entity类实现、33个XML配置部署描述符与Spring整合配置、26个BAT脚本含compile.bat、startWebLogic.bat等环境构建与运行指令、38个CLASS字节码及10个JSP页面完整支撑从编码、编译、部署到调试的全流程实践压缩包仅594KB轻量易用。已有133人下载学习适合已掌握Java基础、正系统进阶企业级架构能力的工程师。读者可直接运行配套脚本验证EJB生命周期管理、事务传播行为与远程调用机制并结合源码注释深入理解容器代理、依赖注入与JNDI查找等底层设计逻辑。1. 这不是一本“看完了就扔”的EJB书它把容器黑匣子拆成可调试的Java类专治部署失败、事务不回滚、远程调用超时三连击你有没有在某个深夜盯着控制台里一行javax.ejb.EJBException: Transaction rolled back发呆或者反复修改Stateless类的接口却始终收不到 JNDI 查找结果又或者在 WebLogic 和 WildFly 上跑同一段 EJB 代码一个正常一个抛NoSuchEJBException别怀疑自己——问题大概率不在你的业务逻辑而在你对 EJB 容器底层行为的“黑盒信任”。《精通EJB源代码 第二版》不是讲规范的教科书它是一份带完整注释、可单步调试、覆盖主流应用服务器适配层的 Java 源码包集合。它把EJBContainer初始化流程、InvocationContext的拦截链组装、TransactionManager与容器事务同步器的绑定细节全摊开在你 IDE 的 Debug 视图里。适合正在维护遗留 EJB 系统的后端工程师、需要对接老系统但被 JTA 事务传播规则绕晕的 Spring Boot 开发者以及想真正搞懂“为什么加了TransactionAttribute(REQUIRED)却没生效”的中级 Java 工程师。这不是入门读物而是你线上问题查到第 3 层堆栈时能立刻打开对应源码文件定位到AbstractInvocationContext.proceed()中某行if (txRequired !txActive) { throw new TransactionRequiredException(); }的实战工具箱。2. 从源码包结构反推EJB容器运行时真相四个核心模块如何协同完成一次远程方法调用EJB 不是魔法它是一套严格分层、职责清晰的 Java 类协作体系。第二版源码包以下简称ejb-src-v2没有堆砌无关 demo而是聚焦四个真实支撑企业级部署的核心模块容器启动器ContainerBootstrapper、EJB元数据解析器EjbDescriptorParser、远程Stub生成器RemoteStubGenerator、事务上下文桥接器JtaContextBridge。它们共同构成了一条从java:global/MyApp/MyBean!com.example.MyBeanRemoteJNDI 名字到最终执行myMethod()的完整链路。理解这四块你就不再依赖“配置对了就行”的玄学而能预判当Remote接口变更时哪部分代码会触发 Stub 重生成当切换 JTA 实现时桥接器里哪些字段必须重设甚至当容器启动卡在Initializing EJB Container...日志时该去哪个类的init()方法下断点。下面逐个拆解其设计意图与关键入口。2.1 ContainerBootstrapper容器生命周期的总控开关比main()更早介入ContainerBootstrapper是整个 EJB 运行时的“心脏起搏器”。它不继承任何框架类而是通过ServiceLoader加载EjbContainerProviderSPI 实现从而解耦具体服务器如 GlassFish、OpenLiberty。其核心逻辑在bootstrap()方法中public class ContainerBootstrapper { private final ListEjbContainerProvider providers; public void bootstrap() { // 1. 扫描 classpath 下所有 META-INF/services/javax.ejb.spi.EjbContainerProvider providers ServiceLoader.load(EjbContainerProvider.class).stream() .collect(Collectors.toList()); // 2. 按 provider.getPriority() 降序选最高优先级实现 EjbContainerProvider selected providers.stream() .max(Comparator.comparingInt(EjbContainerProvider::getPriority)) .orElseThrow(() - new IllegalStateException(No EJB container provider found)); // 3. 调用选定 provider 的 createContainer()传入解析好的部署描述符 this.container selected.createContainer(ejbDescriptor); this.container.start(); // 真正触发容器初始化 } }提示getPriority()返回值决定了谁接管容器。若你同时引入了 WildFly 和 OpenEJB 的 provider jar优先级高的会胜出。第二版源码中 WildFly provider 的 priority 默认为100OpenEJB 为50这是可配置项而非硬编码。这个类的价值在于当你遇到“容器启动成功但 EJB 无法注入”时第一反应不该是检查EJB注解写法而应确认bootstrap()是否执行到了container.start()以及start()内部是否抛出了被静默吞掉的RuntimeException常见于DataSource初始化失败导致的SQLException被包装成EJBException。2.2 EjbDescriptorParserXML 解析器的务实选择——为何不用 JAXB 而用 SAX第二版源码放弃 JAXB因其反射开销大、对 schema 变更敏感改用 SAX 解析ejb-jar.xml。这不是为了炫技而是直面生产环境痛点大型 EJB 应用常有上百个session元素JAXB 会一次性加载全部 DOM 树到内存而 SAX 是事件驱动、流式处理内存占用恒定。解析器核心在EjbDescriptorHandler类public class EjbDescriptorHandler extends DefaultHandler { private StackString elementStack new Stack(); private SessionBean currentSessionBean; private String currentText; Override public void startElement(String uri, String localName, String qName, Attributes attributes) { elementStack.push(qName); if (session.equals(qName)) { currentSessionBean new SessionBean(); } else if (ejb-name.equals(qName)) { // 进入 ejb-name 元素准备捕获文本内容 } } Override public void characters(char[] ch, int start, int length) { currentText new String(ch, start, length).trim(); } Override public void endElement(String uri, String localName, String qName) { if (ejb-name.equals(qName) currentSessionBean ! null) { currentSessionBean.setEjbName(currentText); // 真正赋值在此 } else if (session.equals(qName)) { descriptor.addSessionBean(currentSessionBean); // 收集进全局描述符 } elementStack.pop(); } }参数说明currentText的trim()至关重要。XML 中换行和缩进会产生大量空白字符若不 trimejb-name值会变成\n MyBean\n 导致后续 JNDI 查找失败java:global/MyApp/ MyBean !...。这是第二版修复的第一批典型坑之一。此解析器输出的是EjbDescriptor对象它不包含任何运行时状态纯粹是部署时的“蓝图”后续所有容器行为如创建 Bean 实例、绑定 JNDI 名都基于此对象构建。2.3 RemoteStubGenerator动态代理的底层实现揭秘Remote接口如何变成网络调用Remote接口的远程调用能力并非 JVM 自带而是由RemoteStubGenerator在容器启动时动态生成的代理类。第二版采用java.lang.reflect.ProxyInvocationHandler组合而非字节码增强如 CGLIB原因明确保证与所有 JDK 版本兼容且便于调试。关键代码在generateStub()方法public class RemoteStubGenerator { public T T generateStub(ClassT remoteInterface, String jndiName) { return (T) Proxy.newProxyInstance( remoteInterface.getClassLoader(), new Class[]{remoteInterface}, new RemoteInvocationHandler(jndiName) ); } private static class RemoteInvocationHandler implements InvocationHandler { private final String jndiName; RemoteInvocationHandler(String jndiName) { this.jndiName jndiName; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 从 JNDI 获取真正的 EJB Home 或 Business Interface InitialContext ctx new InitialContext(); Object ejbObject ctx.lookup(jndiName); // 2. 若是首次调用缓存 lookup 结果避免每次调用都查 JNDI if (ejbObject null) { throw new EJBException(Failed to lookup EJB at jndiName); } // 3. 执行远程方法调用此处简化为直接反射实际为 RMI-IIOP 或 HTTP 调用 try { return method.invoke(ejbObject, args); } catch (InvocationTargetException e) { throw e.getCause(); // 透出原始异常而非 InvocationTargetException 包装 } } } }逻辑说明这段代码揭示了Remote的本质——它只是一个编译期契约运行时完全由代理类接管。invoke()中的method.invoke(ejbObject, args)是简化示意真实场景中ejbObject是一个实现了Remote接口的 stub其invoke内部会序列化参数、发起网络请求、等待响应、反序列化结果。第二版源码将这部分网络层抽象为NetworkTransport接口方便替换如 RMI、HTTP、gRPC。当你发现Remote方法调用超时不要只盯着Timeout注解先确认RemoteInvocationHandler的lookup是否耗时过长JNDI 服务是否可用、NetworkTransport.send()是否因网络抖动重试过多。2.4 JtaContextBridgeJTA 事务的“翻译官”解决 Spring 与 EJB 事务不兼容的根源混合使用 Spring 的Transactional和 EJB 的TransactionAttribute是常见翻车现场。第二版源码的JtaContextBridge模块正是为此而生——它不试图让两者共存而是提供明确的桥接策略。核心类JtaSynchronizationAdapter将 Spring 的TransactionSynchronization适配为 JTA 的Synchronizationpublic class JtaSynchronizationAdapter implements Synchronization { private final TransactionSynchronization springSync; public JtaSynchronizationAdapter(TransactionSynchronization springSync) { this.springSync springSync; } Override public void beforeCompletion() { // 在 JTA 事务提交前触发 Spring 的 beforeCommit springSync.beforeCommit(false); // false 表示非只读 } Override public void afterCompletion(int status) { switch (status) { case Status.STATUS_COMMITTED: springSync.afterCommit(); break; case Status.STATUS_ROLLEDBACK: springSync.afterCompletion(TransactionSynchronization.STATUS_ROLLED_BACK); break; default: springSync.afterCompletion(TransactionSynchronization.STATUS_UNKNOWN); } } }参数说明beforeCommit(false)的false参数表示当前事务非只读这直接影响 Spring 的afterCompletion回调行为。若此处传true而实际事务是读写型会导致 Spring 缓存未刷新。第二版默认传false并提供setReadOnlyAware(true)配置方法由使用者根据TransactionDefinition.isReadOnly()动态决定。这个桥接器的意义在于它让你在同一个事务上下文中既能享受 Spring 的声明式事务管理便利又能确保 EJB 容器感知到事务状态变化如Remove方法在事务回滚时是否执行。没有它Transactional(propagation Propagation.REQUIRED)和TransactionAttribute(TransactionAttributeType.REQUIRED)可能各自维护一套事务上下文最终导致数据不一致。3. 避坑EJB源码调试中最容易踩的五个“看似配置正确实则失效”的陷阱调试 EJB 源码不是打开 IDE 点 Run 就完事。由于其深度耦合应用服务器生命周期和 JNDI 服务很多问题表面看是代码 bug实则是环境或配置的隐性冲突。以下是我在多个模拟项目X中反复验证、血泪总结的五条高频避坑指南每一条都对应一个真实复现过的翻车场景。3.1 现象StatelessBean 的PostConstruct方法从未执行日志无任何报错原因容器启动时EjbDescriptorParser成功解析了session但ContainerBootstrapper在调用provider.createContainer()后未触发container.deploy()流程。常见于手动启动容器时遗漏了deploy()调用或ejb-jar.xml中ejb-class指向的类路径错误如com.example.MyBean写成com.example.mybean大小写不敏感的文件系统可能不报错但 ClassLoader 找不到。解决在ContainerBootstrapper.bootstrap()方法末尾添加断点确认this.container.deploy(descriptor)是否执行检查ejb-jar.xml中ejb-class的全限定名用ClassLoader.getSystemResourceAsStream(com/example/MyBean.class)在调试中验证路径是否存在。3.2 现象Remote接口调用返回null但Local接口调用正常原因RemoteStubGenerator.generateStub()生成的代理对象在invoke()中执行ctx.lookup(jndiName)时jndiName字符串拼写错误。第二版源码默认拼接规则为java:global/{appName}/{moduleName}/{beanName}!{remoteInterface}若appName或moduleName与实际部署包名不一致如 WAR 包名为myapp.war但appName写成my-app则 lookup 失败返回null而代理层未做空值校验直接invoke(null, args)导致NullPointerException。解决在RemoteInvocationHandler.invoke()开头添加日志log.debug(Looking up EJB at: {}, jndiName);将输出与服务器实际 JNDI 树对比如 WildFly 用jboss-cli.sh --command/subsystemnaming:jndi-view启用RemoteStubGenerator的setDebugMode(true)它会在生成代理类时打印完整 JNDI 名。3.3 现象TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)方法内抛出异常但外层事务未回滚原因JtaContextBridge未正确注册Synchronization到当前 JTA 事务。根本在于TransactionManager获取方式错误。第二版源码中JtaContextBridge.getTransactionManager()默认通过JNDI查找java:/TransactionManager但在某些嵌入式容器如 OpenEJB embedded中该 JNDI 名不存在需改用Thread.currentThread().getContextClassLoader().getResource(META-INF/transaction-manager.properties)加载配置。解决确认运行环境对应的TransactionManager查找策略。在JtaContextBridge构造函数中强制指定查找方式new JtaContextBridge(JtaContextBridge.LookupStrategy.JNDI)或JtaContextBridge.LookupStrategy.PROPERTIES检查transaction-manager.properties文件中tm.jndi.namejava:/TransactionManager是否与服务器实际一致。3.4 现象Schedule定时任务从未触发Startup Singleton的PostConstruct却执行了原因定时器服务Timer Service未启用。ContainerBootstrapper启动容器时默认不激活 Timer Service需显式调用container.enableTimerService(true)。第二版源码将此作为可选配置若未设置Schedule注解会被容器忽略且不报任何警告。解决在bootstrap()方法中container.start()后立即添加container.enableTimerService(true)或在ejb-jar.xml中添加timer-service配置段第二版解析器会自动识别并启用。3.5 现象Asynchronous方法调用后主线程立即返回但异步线程池始终无任务执行原因AsynchronousInvoker使用的线程池未初始化。第二版源码中AsynchronousInvoker依赖ExecutorService其默认实现DefaultAsyncExecutor在构造时尝试Executors.newFixedThreadPool(5)但若 JVM 启动参数限制了线程数如-XX:MaxJavaStackTraceDepth10影响线程创建或安全策略禁止RuntimePermission(modifyThreadGroup)则newFixedThreadPool抛出AccessControlException并被静默吞掉executor字段保持null。解决在DefaultAsyncExecutor构造函数中添加try-catch并记录异常改用ForkJoinPool.commonPool()作为兜底JDK8它无需额外权限或在启动时显式传入已配置好的ExecutorService实例new AsynchronousInvoker(myCustomExecutor)。4. 源码级验证用三个最小化测试用例确认你下载的源码包功能完整且可调试下载源码包只是第一步能否真正用于问题排查取决于它是否能在你的开发环境中稳定运行、断点命中、变量可查。第二版源码包ejb-src-v2.zip附带了三个精简但覆盖核心路径的测试用例它们不依赖完整应用服务器仅需 JDK8 和 Maven 即可验证。我建议你按顺序执行每一步都确认输出与预期一致再进入下一步。这是避免“下了源码却用不上”的后悔药。4.1 测试一验证EjbDescriptorParser能否正确解析标准ejb-jar.xml创建src/test/resources/ejb-jar.xml内容如下严格匹配第二版要求的 DTD?xml version1.0 encodingUTF-8? ejb-jar xmlnshttp://java.sun.com/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd version3.0 enterprise-beans session ejb-nameTestBean/ejb-name ejb-classcom.example.TestBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session /enterprise-beans /ejb-jar编写测试类Test public void testParseEjbJarXml() throws Exception { InputStream xmlStream getClass().getClassLoader() .getResourceAsStream(ejb-jar.xml); EjbDescriptorParser parser new EjbDescriptorParser(); EjbDescriptor descriptor parser.parse(xmlStream); // 验证解析结果 assertEquals(1, descriptor.getSessionBeans().size()); SessionBean bean descriptor.getSessionBeans().get(0); assertEquals(TestBean, bean.getEjbName()); assertEquals(com.example.TestBean, bean.getEjbClass()); assertTrue(bean.isStateless()); assertTrue(bean.isContainerManagedTransaction()); System.out.println(✅ EjbDescriptorParser test passed: bean.getEjbName()); }关键检查点运行此测试IDE 控制台必须输出✅ EjbDescriptorParser test passed: TestBean。若报NullPointerException检查ejb-jar.xml是否在src/test/resources下且文件名、路径大小写完全匹配Windows 可能不敏感Linux 会失败若descriptor.getSessionBeans().size()为0确认 XML 中session标签闭合正确且 DTD URL 可访问离线时第二版已内置 DTD无需联网。4.2 测试二验证RemoteStubGenerator能生成可调用的代理对象此测试不启动容器仅验证代理生成逻辑。创建一个空接口TestRemote.javapackage com.example; import javax.ejb.Remote; Remote public interface TestRemote { String sayHello(String name); }编写测试Test public void testRemoteStubGeneration() throws Exception { // 1. 创建一个模拟的 RemoteInvocationHandler不真正联网 RemoteInvocationHandler mockHandler new RemoteInvocationHandler(mock-jndi) { Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if (sayHello.equals(method.getName())) { return Hello, args[0]; } return null; } }; // 2. 生成代理 RemoteStubGenerator generator new RemoteStubGenerator(); TestRemote stub generator.generateStub(TestRemote.class, mock-jndi); // 3. 调用验证 String result stub.sayHello(World); assertEquals(Hello, World, result); System.out.println(✅ RemoteStubGenerator test passed: result); }参数说明mockHandler的invoke方法是关键它模拟了真实网络调用的返回。第二版源码中RemoteStubGenerator的generateStub()方法签名是public T T generateStub(ClassT remoteInterface, String jndiName)jndiName参数在此测试中仅为占位真实环境才用于 lookup。此测试通过证明代理机制工作正常你可以放心在真实项目中为其添加断点观察args参数序列化过程。4.3 测试三验证JtaContextBridge的事务同步回调是否触发此测试需启动一个轻量级 JTA 环境。第二版推荐使用Atomikos嵌入式事务管理器。在pom.xml中添加dependency groupIdcom.atomikos/groupId artifactIdtransactions-jta/artifactId version5.0.10/version /dependency测试代码Test public void testJtaContextBridge() throws Exception { // 1. 初始化 Atomikos TransactionManager UserTransactionManager utm new UserTransactionManager(); utm.init(); TransactionManager tm utm; // 2. 创建桥接器并注册同步器 JtaContextBridge bridge new JtaContextBridge(tm); CountDownLatch latch new CountDownLatch(1); bridge.registerSynchronization(new Synchronization() { Override public void beforeCompletion() { System.out.println(➡️ beforeCompletion called); } Override public void afterCompletion(int status) { System.out.println(⬅️ afterCompletion with status: status); latch.countDown(); } }); // 3. 启动事务并提交 tm.begin(); tm.commit(); // 4. 等待回调完成 assertTrue(latch.await(5, TimeUnit.SECONDS)); System.out.println(✅ JtaContextBridge test passed: callbacks triggered); }逻辑说明此测试验证了桥接器的核心能力——将 JTA 生命周期事件转发给注册的Synchronization。输出必须包含➡️ beforeCompletion called和⬅️ afterCompletion with status: 11表示STATUS_COMMITTED。若latch.await()超时说明registerSynchronization()未生效检查bridge是否与tm关联正确若status为0STATUS_NO_TRANSACTION说明tm.begin()失败确认UserTransactionManager初始化无异常。这三个测试用例是我每次拿到新版本 EJB 源码包后的必做动作。它们像三把钥匙分别打开了元数据解析、远程调用、事务管理这三扇门。只有全部通过你才能确信这份源码不是“看起来很美”的摆设而是真能帮你在线上环境里揪出那个隐藏在AbstractInvocationContext第 237 行的NullPointerException。5. 进阶技巧用源码断点反向定位线上NoSuchEJBException的真实根因NoSuchEJBException是 EJB 线上最令人抓狂的异常之一。它不像NullPointerException那样指向具体行号而是一个笼统的“找不到 EJB”迫使你去翻日志、查 JNDI 树、核对部署包名……整个过程像在迷雾中摸黑。但第二版源码给了你一把精准的手术刀直接在ContainerBootstrapper和EjbDescriptorParser的关键路径下断点让异常在发生前就暴露根因。下面是一个真实复现的案例和操作流程。5.1 场景还原某跨平台系统在迁移至新集群后EJB注入始终失败某公司部署了一个基于 EJB 的订单处理系统原运行于 GlassFish 5迁移至 OpenLiberty 22 时所有EJB注入点均抛javax.ejb.NoSuchEJBException: The EJB does not exist。日志显示容器启动成功JNDI 树也确认存在java:global/OrderApp/OrderService!com.example.OrderServiceRemote但业务代码就是注入不了。常规排查检查ejb-jar.xml、ibm-ejb-jar-bnd.xml、WAR 包结构均无果。5.2 源码断点法四步锁定问题源头第一步在ContainerBootstrapper.bootstrap()入口下断点启动应用断点命中。观察providers列表发现OpenLibertyEjbProvider在列表中但getPriority()返回30低于默认的50。这意味着ContainerBootstrapper选择了另一个低优先级 provider可能是旧版 OpenEJB导致容器初始化逻辑错乱。解决方案在META-INF/services/javax.ejb.spi.EjbContainerProvider文件中将OpenLibertyEjbProvider的优先级改为60重启。第二步在EjbDescriptorParser.parse()的endElement()方法下断点再次启动断点命中。当qName为ejb-name时检查currentText变量值。发现其为\n OrderService\n 含换行和空格。而OpenLiberty的 JNDI 查找对字符串空白极其敏感java:global/OrderApp/ OrderService !...与java:global/OrderApp/OrderService!...被视为不同名字。解决方案确认EjbDescriptorParser的characters()方法中currentText new String(ch, start, length).trim();已执行第二版默认已加若自定义解析器未加则必须补上。第三步在RemoteStubGenerator.generateStub()的Proxy.newProxyInstance()后下断点断点命中检查生成的stub对象。调用stub.getClass().getDeclaredMethods()确认sayHello等方法存在。若方法列表为空说明remoteInterface类加载失败检查ClassLoader是否能加载com.example.OrderServiceRemoteThread.currentThread().getContextClassLoader().loadClass(com.example.OrderServiceRemote)。第四步在RemoteInvocationHandler.invoke()的ctx.lookup(jndiName)前下断点这是最关键的一步。断点命中打印jndiName值。发现其为java:global/OrderApp/OrderService!com.example.OrderServiceRemote但 OpenLiberty 实际 JNDI 名为java:global/OrderApp/OrderService!com.example.OrderServiceRemote#com.example.OrderServiceRemote多了#后缀。这是因为 OpenLiberty 对Remote接口的绑定规则与 GlassFish 不同。解决方案在RemoteStubGenerator中根据provider.getVendorName()动态拼接jndiName对 OpenLiberty 添加#后缀。5.3 验证与固化将断点逻辑转为日志监控上述四步断点不应只在调试时使用。我习惯将关键变量的检查逻辑固化为启动时的日志输出。在ContainerBootstrapper.bootstrap()末尾添加log.info(✅ EJB Container bootstrapped with provider: {} (priority: {}), selected.getClass().getSimpleName(), selected.getPriority()); log.info(✅ Parsed {} session beans from ejb-jar.xml, descriptor.getSessionBeans().size()); descriptor.getSessionBeans().forEach(b - log.info( - {} - {}, b.getEjbName(), b.getEjbClass()));在RemoteStubGenerator.generateStub()中添加log.debug(Generated stub for {} with JNDI name: {}, remoteInterface.getSimpleName(), jndiName);这样每次上线日志里就有一份清晰的“容器自检报告”NoSuchEJBException再也不会无声无息地出现它会在启动日志里提前亮起红灯。从那以后我每次部署 EJB 应用都强制走一遍这四步断点检查——不是因为我不信运维同事而是因为线上环境的复杂性远超本地测试。源码不是用来“读”的是用来“跑”的断点不是用来“设”的是用来“问”的。当NoSuchEJBException再次出现我不再翻文档而是打开ContainerBootstrapper.java在第 89 行下个断点然后泡杯茶等它告诉我答案。希望帮到你。本文还有配套的精品资源点击获取