2016-05-04 8 views
0

Ich arbeite an einem Multimodul-Projekt, das aus vielen WAR-Dateien besteht. Die Projekte verwenden Spring 4.0.5 zum Verwalten von Abhängigkeiten und AspectJ 1.8.5 mit Ladezeitweben, um AOP zu unterstützen (Spring-Basis-AOP-Unterstützung ist in diesem Projekt nicht erforderlich). Auch gibt es eine aop.xml im Verzeichnis META-INF mit sehr einfacher Konfiguration:AspectJ Ladezeit Weben funktioniert nicht richtig in EAR implementierten Klassen

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

AOP wird hauptsächlich verwendet, verschiedene Dienste und DAOs (anotated mit @Service und @Repository) mit Transactional Verhalten zu liefern (mit Frühling @Transactional Annotation). Zum Beispiel:

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

Oder eine abstrakte Basis DAO, aus dem der Rest DAOs Anwendung erben

@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; 
    } 
    } 
    ... 
} 

Schließlich wird das Projekt Maven für Gebäude verwendet und läuft auf JBoss EAP 6.1.

Mit dieser Konfiguration funktioniert alles gut beim Erstellen und Bereitstellen von WAR-Dateien. Aber wenn ich eine einfache EAR-Datei nur mit einer dieser WAR-Dateien darin erstelle, webt die Ladezeit beim Weben alle Klassen bis auf eine, die BaseDAO.

Ich habe mit diesem seit vielen Jahren gekämpft und das einzige, was ich bekommen kann, ist, dass beim Weben der Anwendung das Weben in beiden Fällen fast gleich ist, außer dass in der EAR BaseDAO nicht gewebt wird. Ich kann nicht herausfinden warum. Irgendeine Idee warum das passiert?

PD: Aktivieren von AspectJ Weberei Protokoll zeigt diese, wenn sie von einem WAR-Boot Anwendung:

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

Aber wenn die EAR mit diesem Krieg Boote im Innern wird BaseDAO Klasse völlig ignoriert:

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

Antwort

0

Schließlich Wir haben herausgefunden, wo das Problem lag. Es war in der jboss-deployment-structure.xml. Jeder Krieg im Projekt hatte seinen eigenen jboss-Deployment-structure.xml mit einigen Ausnahmen:

<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> 

Aber in der EAR-Bereitstellung des spezifische jboss-Deployment-structure.xml EAR fehlte, so dass die Klassenlader arbeiten in eine sehr andere Art und Weise, die Probleme zu schaffen, die ich in meiner Frage poste. Einfach die jboss-deployment-structure.xml (die EAR-Datei, also eine Kombination aus den WAR-Dateien) in META-INF des EARs zu setzen, löste das Problem.

Hoffe das hilft jemand mit ähnlichen Problemen.

Verwandte Themen