AspectJ加载时编织在EAR部署的类中不能正常工作

Question

我正在处理一个由许多WAR文件组成的多模块项目。这些项目使用Spring 4.0.5来管理依赖关系，使用带有加载时间编织的AsheJ 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主要用于提供各种服务和具有事务性行为（使用spring的@Transactional注释）的DAO（使用@Service和@Repository进行描述）。例如：

@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，应用程序的其余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文件，加载时编织会编织除BaseDAO之外的所有类。

我已经为此挣扎了很多时间，我唯一能得到的是，在应用程序启动时，编织在两种情况下几乎相同，除了在EAR中，BaseDAO没有编织。我不知道为什么。知道为什么会发生这种情况吗？

P. D.：从WAR启动应用程序时，启用AsheJ编织日志会显示这一点：

 ...
 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部署结构中。xml。项目中的每一场战争都有自己的jboss部署结构。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丢失了，所以类加载器以非常不同的方式工作，产生了我在问题中发布的问题。简单地将jboss-deployment-structure.xml（EAR，即WAR的组合）放入EAR的META-INF解决了问题。

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