Question

我正在处理由许多WAR文件组成的多模块项目。这些项目使用Spring 4.0.5来管理依赖项，而使用负载时间编织的AspectJ 1.8.5来支持AOP（Spring基本的AOP支持在这个项目中并不令人满意）。此外，META-INF目录中有一个aop.xml，配置非常简单：

<aspectj>
  <aspects>
   <!--No need to specify any aspect here-->
  </aspects>
  <weaver options="-XnoInline -verbose">
    <include within="com.myproject..*" />   
  </weaver>
</aspectj>

AOP主要用于提供各种服务和DAO（用@Service和@Repository分配）和Transactional行为（使用spring的@Transactional注释）。例如：

@Service(value = "alertService")
public class AlertServiceImpl implements IAlertService, Serializable {
  ...
  @Transactional(rollbackFor = Exception.class)
  @Override
  public Alert createAlert(Alert alert) {
    alertDAO.create(alert);
    return alert;
  }
  ...
}

或其他应用程序的DAO继承的抽象Base DAO

@Repository
public abstract class BaseDAO<E extends IBusinessObject, PK extends Serializable> {
  ...
  @Transactional(readOnly = true)
  public <C extends E> C findFirstByFields(Class<C> type, String[] fields, Object[] values, String[] dependencies)
      throws ModelException {
    List<C> list = findAllByFields(type, fields, values, null, null, 1, null);
    if (list.isEmpty()) {
      return null;
    } else {
      C obj = list.get(0);
      loadDependencies(obj, dependencies);
      return obj;
    }
  }
  ...
}

最后，该项目使用maven构建并在JBoss EAP 6.1上运行。

因此，使用此配置，在构建和部署WAR文件时一切正常。但是，如果我只使用其中一个WAR文件构建一个简单的EAR文件，那么加载时间编织会编织所有的clases但只有一个，即BaseDAO。

我一直在努力解决这个问题，我唯一可以得到的是，在应用程序启动时，编织在两种情况下几乎相同，只是在EAR中，BaseDAO没有编织。我无法弄清楚原因。知道为什么会这样吗？

P.D。：启用AspectJ编织日志在从WAR启动应用程序时显示：

 ...
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure1'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure3'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure5'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.subproject.services.Repository$AjcClosure1'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.model.dao.BaseDAO$AjcClosure1'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.model.dao.BaseDAO$AjcClosure3'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.model.dao.BaseDAO$AjcClosure5'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.model.dao.BaseDAO$AjcClosure7'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.subproject.model.dao.LastDocumentNumberDAO$AjcClosure1'
 ...

但是在内部使用此战争启动EAR时，BaseDAO类将被完全忽略：

 ...
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure1'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure3'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.commons.services.CommonService$AjcClosure5'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.subproject.services.Repository$AjcClosure1'
 ServerService Thread Pool -- 227 ? [ModuleClassLoader@1b3a9e75] debug generating class 'com.myproject.subproject.model.dao.LastDocumentNumberDAO$AjcClosure1'
 ...

Answer 1

最后我们找到了问题所在。它位于jboss-deployment-structure.xml中。项目中的每个战争都有自己的jboss-deployment-structure.xml和一些排除项：

<jboss-deployment-structure>
  <deployment>
    <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
    <exclusions>
      <module name="org.apache.log4j" />
      <module name="org.slf4j" />
      <module name="org.apache.commons.logging" />
      <module name="org.log4j" />
      <module name="org.jboss.logging" />
      <module name="org.javassist" />
      <module name="org.hibernate.validator" />
      <module name="org.jboss.ws.cxf" />
    </exclusions>
    <exclude-subsystems>
      <subsystem name="webservices" />
    </exclude-subsystems>
  </deployment>
</jboss-deployment-structure>

但是在EAR部署中，EAR的特定jboss-deployment-structure.xml丢失了，所以类加载器以一种非常不同的方式工作，创建了我在我的问题中发布的问题。简单地在EAR的META-INF中放置jboss-deployment-structure.xml（EAR one，即WAR的组合）解决了这个问题。

希望这可以帮助有类似问题的人。

AspectJ加载时间编织在EAR部署的类中无法正常工作

1 个答案: