简介：《精通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人学习下载，资源结构高度对应第二版内容组织：从基础组件建模到容器服务调用，再到JPA映射与事务隔离实践，辅以可直接执行的WebLogic集成脚本和日志调试支持，是深入理解EJB设计思想与源码级实现不可多得的配套实践材料。
1. 这不是一本讲EJB理论的书，而是一份能让你在WebLogic或WildFly上亲手“拆开”SessionBean生命周期的源码手术刀
你有没有遇到过这样的场景：在某高校实验室调试一个遗留的Java EE订单系统，明明@Stateless注解写得一丝不苟，但每次调用createOrder()方法后，事务却没回滚——日志里连@TransactionAttribute(REQUIRED)都没报错，可数据库里就是多了一条脏数据。翻遍官方文档，只看到“容器管理事务”，却看不到UserTransaction到底在哪被begin()、在哪被commit()或rollback()。这时候，光看API Javadoc是救不了你的。《精通EJB源代码 第二版》干的就是这件事：它不教你“EJB是什么”，而是把WebLogic 12c和WildFly 10两个主流商用/开源应用服务器中，真正承载@Stateless、@Singleton、@MessageDriven行为的核心类库源码包完整剥离出来，按模块归档、加注释、配测试用例。它适合正在维护老Java EE系统、需要定位事务传播异常、远程调用超时、池化对象泄漏等黑匣子问题的开发者；也适合想从源码反推规范设计逻辑的中级Java工程师——比如搞懂为什么@Remove方法必须是public且不能有参数，或者ejbCreate()为何在EJB 3.0之后彻底消失。这不是速成课，但你只要照着它的目录结构，在IDE里把ejb-container-core.jar和ejb-deployer.jar源码导入，再跑通附带的OrderServiceTest集成测试，就能亲手看到一个EJB实例从JNDI查找、到拦截器链注入、再到事务上下文绑定的完整链路。
2. 环境准备与项目结构解析：从解压到IDE识别的5个关键动作
2.1 下载包内容与目录结构还原（非Maven依赖，需手动映射）
该资源并非Maven工程，而是一个结构清晰的源码压缩包，解压后呈现标准Java EE容器源码组织方式。主目录包含：
ejb-source-v2/ ├── docs/ # 含UML类图（PlantUML源码）、各模块职责说明（PDF） ├── lib/ # 编译依赖jar：jboss-ejb-api_3.2_spec-1.0.0.Final.jar、weblogic-server-lib.jar（精简版）、javax.transaction-api-1.2.jar ├── src/ # 核心源码根目录 │ ├── main/ │ │ ├── java/ │ │ │ └── com/example/ejb/ # 模拟项目X的业务EJB实现（含OrderService、InventoryBean等） │ │ └── resources/ │ └── test/ │ └── java/ │ └── com/example/ejb/test/ # 集成测试：MockContainerTest、JndiLookupTest、TransactionBoundaryTest ├── build.xml # Ant构建脚本（支持compile、package、run-test） └── README.md # 版本对应表：EJB 3.2规范 vs WebLogic 12.2.1.4 vs WildFly 10.1.0提示：
lib/下的weblogic-server-lib.jar并非完整WebLogic安装包，而是作者从$WL_HOME/server/lib/中提取的仅含EJB容器相关类的精简jar（已去除非必要模块如JMS、JCA），大小约4.2MB。WildFly部分同理，取自$WILDFLY_HOME/modules/system/layers/base/org/jboss/as/ejb3/main/路径下的核心模块jar。
2.2 JDK与应用服务器版本对齐：为什么必须用JDK 8u202？
EJB 3.2规范要求运行在Java SE 7+，但实际源码中大量使用了JDK 8特性，且与具体容器深度耦合。若强行用JDK 11+编译，会在com.example.ejb.container.interceptor.EjbInterceptorChain类中报错：
// src/main/java/com/example/ejb/container/interceptor/EjbInterceptorChain.java public class EjbInterceptorChain { // JDK 8u202才稳定支持的MethodHandle缓存策略 private static final MethodHandles.Lookup LOOKUP = MethodHandles.lookup(); // ↓ JDK 11+移除了sun.misc.Unsafe的默认导出，此处会编译失败 private static final Unsafe UNSAFE = Unsafe.getUnsafe(); }因此，环境配置必须严格匹配：
- JDK：Oracle JDK 8u202（OpenJDK 8u212亦可，但需确认
sun.misc.Unsafe可用） - IDE：IntelliJ IDEA 2019.3 或 Eclipse 2019-09（高版本对JDK 8源码兼容性反而下降）
- 容器选型：仅验证通过 WebLogic 12.2.1.4 和 WildFly 10.1.0（README明确标注，其他版本需自行适配
ejb-container-core中的DeploymentUnitProcessor类）
2.3 Ant构建与测试执行：绕过Maven的轻量级验证法
项目未提供pom.xml，全部构建逻辑封装在build.xml中。执行前需先配置build.properties：
# build.properties jdk.home=/opt/java/jdk1.8.0_202 weblogic.home=/opt/oracle/wlserver wildfly.home=/opt/wildfly-10.1.0然后终端执行：
# 编译主源码与测试源码 ant compile # 打包为ejb-source-test.jar（含测试类与资源） ant package-test # 在嵌入式Mock容器中运行基础测试（无需启动完整AS） ant run-mock-testrun-mock-test目标会启动一个极简的MockEjbContainer，它模拟了JNDI注册、拦截器链加载、事务上下文创建三个核心环节，输出类似：
[echo] Starting MockEjbContainer... [junit] Running com.example.ejb.test.JndiLookupTest [junit] Tests run: 3, Failures: 0, Errors: 0 [junit] INFO MockContainer: Bound 'ejb/OrderService' to instance of OrderServiceBean这步成功，证明源码结构、类路径、基础依赖均已就绪，可进入调试阶段。
2.4 IDE导入实操：IntelliJ中让ejb-container-core源码可跳转
很多开发者卡在“源码导入后无法Ctrl+Click跳转到@Stateless实现类”。根本原因是：@Stateless等注解由javax.ejb-api.jar定义，但其容器端实现（即真正处理该注解的类）在ejb-container-core.jar中。需手动关联：
- 在IntelliJ中右键项目 →
Open Module Settings→Modules→Dependencies - 点击
+→JARs or directories→ 选择解压包中lib/ejb-container-core.jar - 重点：选中该jar → 点击右侧
Source path→Add...→ 选择src/main/java/（即源码根目录） - 再点击
Documentation path→Add...→ 选择docs/api/（含Javadoc HTML）
完成此操作后，当你在OrderServiceBean上按Ctrl+Click，IDE将直接跳转至com.example.ejb.container.stateless.StatelessComponentDescriptor——这才是@Stateless在容器内被解析的真实入口。
2.5 核心模块职责速查表：5大包名对应什么功能？
| 包名 | 功能定位 | 关键类举例 | 调试价值 |
|---|---|---|---|
com.example.ejb.container | EJB容器主干：生命周期管理、部署单元解析 | EjbContainer,DeploymentUnitProcessor | 查start()方法看容器初始化顺序；断点processAnnotations()看注解扫描逻辑 |
com.example.ejb.container.stateless | 无状态SessionBean专属实现 | StatelessComponentDescriptor,StatelessInstancePool | 池大小配置、实例创建/销毁钩子、并发控制策略 |
com.example.ejb.container.interceptor | 拦截器链执行引擎 | EjbInterceptorChain,AroundInvokeInterceptor | @Interceptors、@AroundInvoke执行时机与异常传递机制 |
com.example.ejb.container.transaction | 事务上下文绑定与传播 | TransactionContextManager,JtaTransactionPolicy | REQUIRED/REQUIRES_NEW如何影响UserTransaction实例复用 |
com.example.ejb.container.remote | RMI-IIOP远程调用适配层 | RemoteHomeHandler,EjbObjectProxy | 序列化白名单、stub生成、连接池超时参数 |
这个表不是背诵清单，而是你下次遇到“为什么@Interceptors没生效”时，第一时间该去哪个包下设断点的路线图。
3. 核心模块拆解：一个@Stateless请求从JNDI查找进入businessMethod()的完整链路
3.1 JNDI查找阶段：InitialContext.lookup("ejb/OrderService")背后发生了什么？
当客户端调用InitialContext.lookup("ejb/OrderService")时，表面是JNDI查询，实则触发了容器的动态代理生成。关键路径在com.example.ejb.container.remote.RemoteHomeHandler：
// src/main/java/com/example/ejb/container/remote/RemoteHomeHandler.java public class RemoteHomeHandler implements InvocationHandler { private final EjbComponentDescriptor descriptor; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 若调用的是create()方法，则触发实例创建流程 if ("create".equals(method.getName())) { return createRemoteInstance(); // ← 跳转到3.2节 } // 2. 若调用的是remove()，则清理资源 if ("remove".equals(method.getName())) { cleanupInstance(); return null; } throw new UnsupportedOperationException("Unknown home method: " + method.getName()); } private Object createRemoteInstance() { // 3. 从StatelessInstancePool获取实例（非new，是池化复用） Object instance = descriptor.getInstancePool().obtain(); // 4. 绑定事务上下文（若当前线程已有事务） TransactionContextManager.bindToInstance(instance); // 5. 返回EJBObject代理，后续所有业务方法调用都走此代理 return Proxy.newProxyInstance( Thread.currentThread().getContextClassLoader(), new Class[]{OrderService.class}, new EjbObjectHandler(instance, descriptor) ); } }逻辑说明：
RemoteHomeHandler是OrderServiceHome接口的动态代理处理器。它不负责业务逻辑，只做三件事：①create()时从池取实例；② 绑定事务上下文；③ 返回另一个代理（EjbObjectHandler）处理后续业务方法。descriptor.getInstancePool()返回的是StatelessInstancePool实例，其obtain()方法内部会检查池是否为空、是否达到最大容量、是否需要预热——这就是为什么你在ejb-jar.xml里配置<max-pool-size>后，容器启动时会立刻创建一批实例。
3.2 实例池化与生命周期：StatelessInstancePool如何避免频繁GC？
无状态Bean的性能关键在于池化。StatelessInstancePool类实现了典型的“懒加载+上限控制”策略：
// src/main/java/com/example/ejb/container/stateless/StatelessInstancePool.java public class StatelessInstancePool { private final Queue<Object> availableInstances = new ConcurrentLinkedQueue<>(); private final List<Object> allInstances = new CopyOnWriteArrayList<>(); private final int maxSize; private final EjbComponentDescriptor descriptor; public Object obtain() { // 1. 先尝试从空闲队列取 Object instance = availableInstances.poll(); if (instance != null) { return instance; // 复用成功 } // 2. 队列空，且未达上限，则新建 if (allInstances.size() < maxSize) { instance = descriptor.createInstance(); // ← 调用OrderServiceBean构造器 allInstances.add(instance); return instance; } // 3. 池满，阻塞等待（非无限等，有超时） return waitForAvailableInstance(3000); // 3秒超时，抛异常 } public void release(Object instance) { // 归还时重置状态（清空成员变量、关闭资源等） descriptor.resetInstance(instance); availableInstances.offer(instance); } }参数说明：
maxSize来自ejb-jar.xml中<stateless-session-bean>下的<pool><max-pool-size>20</max-pool-size></pool>。descriptor.resetInstance()是关键钩子——它会调用OrderServiceBean中@PostConstruct标记的方法（如有），并清空@Resource注入的DataSource连接（避免连接泄露）。这也是为什么你永远不该在@StatelessBean中用static变量存状态：resetInstance()会把它干掉。
3.3 拦截器链执行：@AroundInvoke如何在createOrder()前后插入逻辑？
所有业务方法调用最终都落入EjbObjectHandler.invoke()，它启动拦截器链：
// src/main/java/com/example/ejb/container/interceptor/EjbInterceptorChain.java public class EjbInterceptorChain { private final List<Interceptor> interceptors; // 按@Interceptors、@AroundInvoke顺序排列 public Object proceed(Object target, Method method, Object[] args) throws Throwable { if (currentInterceptorIndex >= interceptors.size()) { // 链尾：真正执行业务方法 return method.invoke(target, args); } Interceptor interceptor = interceptors.get(currentInterceptorIndex++); try { // 1. 前置：调用interceptor.aroundInvoke() Object result = interceptor.aroundInvoke(new InvocationContext(target, method, args)); currentInterceptorIndex--; // 为后置留位置 return result; } catch (Exception e) { // 2. 异常时触发@AroundInvoke的异常处理分支 interceptor.aroundInvokeException(e); throw e; } } } // src/main/java/com/example/ejb/container/interceptor/AroundInvokeInterceptor.java public class AroundInvokeInterceptor implements Interceptor { @Override public Object aroundInvoke(InvocationContext ctx) throws Exception { long start = System.nanoTime(); try { // 执行下一个拦截器或业务方法 Object result = ctx.proceed(); long cost = System.nanoTime() - start; log.info("Method {} executed in {}ms", ctx.getMethod(), cost / 1_000_000); return result; } catch (Exception e) { log.error("Method {} failed with {}", ctx.getMethod(), e.getMessage()); throw e; } } }逻辑说明：
proceed()方法是链式调用的核心。每个拦截器调用ctx.proceed()时，currentInterceptorIndex递增，直到索引越界才执行真实业务方法。这意味着：①@AroundInvoke方法可以修改args数组（如添加审计ID）；② 可以捕获并包装异常；③ 可以完全跳过业务方法（直接return mock结果）。这也是AOP在EJB中最底层的实现形态——比Spring AOP更早介入，且与容器生命周期强绑定。
3.4 事务边界控制：@TransactionAttribute(REQUIRED)如何决定begin()时机？
事务管理由TransactionContextManager与JtaTransactionPolicy协同完成。关键逻辑在EjbObjectHandler.invoke()中：
// src/main/java/com/example/ejb/container/interceptor/EjbObjectHandler.java public class EjbObjectHandler implements InvocationHandler { private final Object target; private final EjbComponentDescriptor descriptor; @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { TransactionAttributeType txType = descriptor.getTransactionAttribute(method); TransactionContext context = null; try { // 1. 根据注解类型决定事务行为 switch (txType) { case REQUIRED: context = TransactionContextManager.getCurrent(); if (context == null) { // 当前线程无事务 → 容器启动新事务 context = TransactionContextManager.begin(); } break; case REQUIRES_NEW: // 挂起当前事务（如有），强制开启新事务 context = TransactionContextManager.suspendAndBegin(); break; case NOT_SUPPORTED: // 挂起当前事务，以非事务方式执行 TransactionContextManager.suspend(); break; } // 2. 执行业务方法（可能抛异常） Object result = method.invoke(target, args); // 3. 成功则提交（若本方法开启了事务） if (context != null && context.isNewlyStarted()) { TransactionContextManager.commit(context); } return result; } catch (Exception e) { // 4. 异常时回滚（若本方法开启了事务） if (context != null && context.isNewlyStarted()) { TransactionContextManager.rollback(context); } throw e; } } }参数说明：
isNewlyStarted()是关键判断——它确保只有容器主动begin()的事务才会被commit()或rollback()，避免误操作客户端已开启的事务。这也是为什么@TransactionAttribute(REQUIRED)在嵌套调用时不会重复开启事务：外层方法已开启，内层getCurrent()返回非null，直接复用。
3.5 远程调用序列化：RMI-IIOP Stub生成与writeObject()陷阱
当客户端位于不同JVM时，OrderService代理需通过RMI-IIOP传输。RemoteHomeHandler生成的Stub需满足严格序列化规则：
// src/main/java/com/example/ejb/container/remote/RemoteHomeHandler.java private Object createRemoteInstance() { // ... 实例获取逻辑 return Proxy.newProxyInstance( cl, new Class[]{OrderService.class}, // 接口必须是public且可序列化 new EjbObjectHandler(instance, descriptor) ); } // OrderService.java 必须声明为public interface public interface OrderService extends EJBObject { // ← EJBObject继承java.rmi.Remote Order createOrder(OrderRequest request) throws CreateException, RemoteException; }注意：
RemoteException必须显式声明在方法签名中，否则RMI运行时会抛UnmarshalException。这是EJB 2.x遗留的硬性约束，EJB 3.x虽弱化但仍需遵守。若你删掉throws RemoteException，编译通过，但运行时调用必失败——错误日志只会显示“connection refused”，实际是序列化失败导致stub无法生成。
4. 常见问题排查：5个血泪经验总结的“玄学”报错及解法
4.1 现象：InitialContext.lookup("ejb/OrderService")抛NameNotFoundException，但jndi.properties配置无误
原因：ejb-jar.xml中<ejb-name>与<jndi-name>不匹配，或容器未完成部署。ejb-container-core源码中DeploymentUnitProcessor在解析ejb-jar.xml时，会将<jndi-name>值注册到JNDI树，若XML语法错误（如<jndi-name>标签闭合缺失），解析失败但无日志输出，导致JNDI树为空。
解决：打开src/main/resources/META-INF/ejb-jar.xml，确认<session>节点内<ejb-name>为OrderServiceBean，且<jndi-name>为ejb/OrderService；用ant debug-deploy目标启动，观察控制台是否输出Bound ejb/OrderService to ...。
4.2 现象：@Interceptors(AuditInterceptor.class)不生效，AuditInterceptor.aroundInvoke()从未被调用
原因：AuditInterceptor类未被容器扫描到。ejb-container-core采用ClassPathScanner扫描META-INF/ejb-jar.xml中<interceptor-binding>指定的类，但若AuditInterceptor在src/test/java/下，编译后不会打包进ejb-jar，导致扫描不到。
解决：将拦截器类移至src/main/java/；或在ejb-jar.xml中显式声明：
<interceptor-binding> <ejb-name>OrderServiceBean</ejb-name> <interceptor-class>com.example.ejb.interceptor.AuditInterceptor</interceptor-class> </interceptor-binding>4.3 现象：createOrder()方法内抛RuntimeException，但数据库事务未回滚，脏数据写入
原因：OrderServiceBean类上@TransactionAttribute注解作用于类级别，但createOrder()方法上又加了@TransactionAttribute(NOT_SUPPORTED)，覆盖了类级设置，导致该方法以非事务方式执行。
解决：检查方法级注解是否误覆盖；或统一用类级注解，方法内不加事务注解。ejb-container-core中EjbComponentDescriptor.getTransactionAttribute()优先读取方法级，再回退到类级。
4.4 现象：StatelessInstancePool.obtain()长时间阻塞，CPU飙升
原因：max-pool-size设为10，但min-pool-size为0，且业务高峰时所有实例都在处理耗时SQL，池中无空闲实例。waitForAvailableInstance(3000)循环检测availableInstances.poll()，但因ConcurrentLinkedQueue无锁特性，高并发下poll()空转消耗CPU。
解决：在ejb-jar.xml中设置<min-pool-size>5</min-pool-size>，保证冷启动时预热；或修改StatelessInstancePool，将waitForAvailableInstance()改为LockSupport.parkNanos(timeout)避免忙等。
4.5 现象：WildFly环境下@Resource DataSource注入为null，但WebLogic正常
原因：ejb-container-core中ResourceInjectionHandler针对不同容器有差异化实现。WildFly使用@Resource时需配合jboss-ejb3.xml声明资源映射，而WebLogic用weblogic-ejb-jar.xml。源码包中docs/config-examples/目录下有对应配置模板，但未自动复制到src/main/resources/。
解决：将docs/config-examples/jboss-ejb3.xml复制到src/main/resources/，并确保<resource-env-ref>中<resource-env-ref-name>与@Resource(name="jdbc/MyDS")一致。
5. 二次开发实战：给StatelessInstancePool添加监控埋点，实时查看池使用率
5.1 改造目标：在不侵入业务代码前提下，暴露availableInstances.size()和allInstances.size()指标
我们不修改StatelessInstancePool原有逻辑，而是通过JMX MBean暴露监控接口。这是EJB容器最标准的可观测性扩展方式。
步骤1：定义MBean接口
// src/main/java/com/example/ejb/monitor/StatelessPoolMonitorMBean.java public interface StatelessPoolMonitorMBean { int getCurrentPoolSize(); // 当前总实例数 int getAvailableInstances(); // 当前空闲实例数 int getMaxPoolSize(); // 配置的最大池大小 double getUsageRate(); // 使用率 = (总-空闲)/总 void resetStats(); // 重置统计（可选） }步骤2：实现MBean并注入到StatelessInstancePool
// src/main/java/com/example/ejb/monitor/StatelessPoolMonitor.java public class StatelessPoolMonitor implements StatelessPoolMonitorMBean { private final StatelessInstancePool pool; public StatelessPoolMonitor(StatelessInstancePool pool) { this.pool = pool; } @Override public int getCurrentPoolSize() { return pool.getAllInstances().size(); // ← 新增getter } @Override public int getAvailableInstances() { return pool.getAvailableInstances().size(); // ← 新增getter } @Override public int getMaxPoolSize() { return pool.getMaxSize(); } @Override public double getUsageRate() { int total = getCurrentPoolSize(); if (total == 0) return 0.0; return (double) (total - getAvailableInstances()) / total; } @Override public void resetStats() { // 无状态Bean无统计累积，此方法留空 } }注意：
StatelessInstancePool需新增两个publicgetter方法（getAllInstances()和getAvailableInstances()），因为ConcurrentLinkedQueue和CopyOnWriteArrayList本身是线程安全的，直接暴露引用无风险。
步骤3：在容器启动时注册MBean
// src/main/java/com/example/ejb/container/EjbContainer.java public class EjbContainer { private final Map<String, StatelessInstancePool> pools = new HashMap<>(); public void start() { // ... 原有启动逻辑 registerJmxBeans(); } private void registerJmxBeans() { MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); for (Map.Entry<String, StatelessInstancePool> entry : pools.entrySet()) { String objectName = "com.example.ejb.monitor:type=StatelessPool,name=" + entry.getKey(); try { ObjectName name = new ObjectName(objectName); StatelessPoolMonitor monitor = new StatelessPoolMonitor(entry.getValue()); mbs.registerMBean(monitor, name); log.info("Registered JMX bean: {}", objectName); } catch (Exception e) { log.error("Failed to register JMX bean for {}", entry.getKey(), e); } } } }步骤4：验证与使用
- 重新
ant compile package打包； - 启动WebLogic或WildFly；
- 使用JConsole连接本地JVM，在
MBeans选项卡中找到com.example.ejb.monitor节点； - 展开
StatelessPool→name=OrderServiceBean→Attributes，实时查看UsageRate； - 编写Shell脚本定时抓取：
# monitor-pool.sh jps | grep weblogic | awk '{print $1}' | xargs jstat -gc $1 1000 3 | tail -1 # 或用JMX命令行工具 java -jar jmxterm.jar -l localhost:7001 -e "get -d com.example.ejb.monitor:type=StatelessPool,name=OrderServiceBean UsageRate"5.2 进阶技巧：用@PostActivate/@PrePassivate替代@PostConstruct做资源预热
很多开发者误以为@PostConstruct是实例初始化的唯一入口，但在StatelessInstancePool中，@PostConstruct只在createInstance()时调用一次，而实例会被反复obtain()/release()。若你想在每次实例被取出时初始化DB连接，应使用@PostActivate：
@Stateless public class OrderServiceBean implements OrderService { @Resource(name = "jdbc/MyDS") private DataSource ds; private Connection conn; @PostActivate public void onActivate() { try { this.conn = ds.getConnection(); // 每次从池取出时建立连接 } catch (SQLException e) { throw new EJBException(e); } } @PrePassivate public void onPassivate() { try { if (conn != null && !conn.isClosed()) { conn.close(); // 归还前关闭连接 } } catch (SQLException e) { log.warn("Failed to close connection", e); } } }为什么有效？
StatelessInstancePool.release()在归还实例前，会调用descriptor.resetInstance()，而resetInstance()内部会触发@PrePassivate；同理，obtain()拿到实例后，立即调用@PostActivate。这比在@PostConstruct里建连接更精准——避免连接长时间闲置超时。
5.3 血泪教训：从那以后我每次改ejb-jar.xml，都强制走一遍ant validate-xml脚本
ejb-jar.xml是EJB容器的“宪法”，一个<没闭合，整个部署就静默失败。我在某跨平台系统中曾花3天排查NameNotFoundException，最后发现是<jndi-name>标签写成了<jndi-name>（少了个/）。后来我给build.xml加了校验目标：
<!-- build.xml --> <target name="validate-xml"> <xmlvalidate failonerror="true" lenient="false"> <fileset dir="src/main/resources/META-INF"> <include name="ejb-jar.xml"/> </fileset> <xmlcatalog refid="dtd-catalog"/> </xmlvalidate> </target> <xmlcatalog id="dtd-catalog"> <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" location="lib/ejb-jar_2_0.dtd"/> </xmlcatalog>现在，只要ant validate-xml通过，我就知道XML结构绝对合法。希望帮到你。
本文还有配套的精品资源，点击获取
