2012-02-23 91 views
2

我使用AspectJ設置LTW並且非常快速且成功。下面是設置: 的beans.xml:AspectJ和Spring LTW在上傳時不起作用

<context:annotation-config /> 
<aop:aspectj-autoproxy /> 
<context:spring-configured /> 
<context:load-time-weaver /> 
<context:component-scan base-package="com.test.service" /> 

我的服務,將被裝配到一個類:

@Service 
public class MyService { 
} 

父類:

public class Bar { 
} 

的配置類,即autowires該服務並擴展Bar。

@Configurable 
public class BarExtended extends Bar{ 
    @Autowired 
    private MyService service; 
    public MyService getWeavedInObject(){ 
     return service; 
    } 
} 

而只是得到了一個全球化志願服務青年父類酒吧類:

public class Foo { 
    private Bar bar; 
    public void setBar(Bar bar) { 
     this.bar = bar; 
    } 
} 

而一個全成測試用例。它只是創建一個BarExtended的實例並檢查LTW是否工作。 Foo類什麼都不做。

@Test 
public void simple(){ 
    Foo foo = new Foo(); 
    BarExtended barExtended = new BarExtended(); 
    assertNotNull("LTW didn't work.", barExtended.getWeavedInObject()); 
} 

此測試運行綠色。但下面的測試失敗:

@Test 
public void simple(){ 
    Foo foo = new Foo(); 
    BarExtended barExtended = new BarExtended(); 
    foo.setBar(barExtended); 
    assertNotNull("LTW didn't work.", barExtended.getWeavedInObject()); 
} 

我只是將BarExtended類設置爲Foo的行。沮喪使AspjectJ不能正常工作。

順便說一句,當我改變Foo類使用BarExtended類(因此不需要向上轉型):

public class Foo { 
    private BarExtended bar; 
    public void setBar(BarExtended bar) { 
     this.bar = bar; 
    } 
} 

上述測試將起作用。有沒有人有一個想法,爲什麼AspjectJ行爲如此奇怪,當一個可配置的對象被上傳?

編輯:Follwing失敗,以及:

@Test 
public void simple() { 
    Foo foo = new Foo(); 
    BarExtended barExtended = new BarExtended(); 
    Bar bar = (Bar) new BarExtended(); 
    foo.setBar(bar); 
    assertNotNull("LTW didn't work.", barExtended.getWeavedInObject()); 
} 

甲不同BarExtended對象設置爲Foo和第一barExtended目的通過AspectJ的忽略。 但使用反射來實例化BarExtended工作:

@Test 
public void simple() throws InstantiationException, IllegalAccessException{ 
    Foo foo = new Foo(); 
    Bar barExtended = (Bar) BarExtended.class.newInstance(); 
    foo.setBar(barExtended); 
    assertNotNull("LTW didn't work.", ((BarExtended)barExtended).getWeavedInObject()); 
} 

奇怪,不是嗎?

非常感謝

問候,

安德烈亞斯

+0

你使用什麼版本的Java,AspectJ? – Ralph 2012-02-24 08:26:16

+0

我使用Java 1.6,aspectj 1.6.12和Spring 3.1.0.RELEASE。 – noCodeFound 2012-02-24 09:56:18

+0

血腥地獄,我也遇到過這個問題。我剛剛在他們的JIRA中提出了這個問題以及可重現的測試用例:https://jira.spring.io/browse/SPR-12901 – bertie 2015-04-10 04:33:32

回答

1

我曾在那裏我還以爲是LTW配置了過去的麻煩,但它不是爲我不太肯定的原因。所以我現在在我的配置中100%明確地對配置文件進行了以下更改,看看它是否全部有效。

<context:load-time-weaver aspectj-weaving="on" /> 

從配置中刪除<aop:aspectj-autoproxy />你不需要它,你必須真的LTW運行。

當你運行你的JUnit測試時,你是否傳遞了vm參數來告訴JUnit LTW代理在哪裏?如果沒有,那麼你沒有運行LTW。

這裏是什麼文件說約<context:load-time-weaver />

激活該應用程序上下文春天的LoadTimeWeaver,可作爲與名 「的LoadTimeWeaver」的bean。任何實現LoadTimeWeaverAware接口的bean都將自動收到 的參考資料;例如,Spring的JPA引導支持。默認編織器是 自動確定。從Spring 2.5開始:檢測Sun的GlassFish,Oracle的OC4J,Spring的VM代理和Spring的ReflectiveLoadTimeWeaver支持的任何ClassLoader(例如, TomcatInstrumentableClassLoader)。通過簡單的 標誌('aspectj-weaving'屬性)指定AspectJ加載時織入的激活,通過Spring的 LoadTimeWeaver註冊AspectJ類變換器。如果在類路徑中存在「META-INF/aop.xml」資源 ,AspectJ編織將被默認激活。這也激活當前應用程序上下文,以便將依賴注入應用到 在Spring bean工廠以外實例化的非託管類(通常使用@Configurable註釋標註 的類)。這隻有在AnnotationBeanConfigurerAspect在類路徑(即spring-aspects.jar)上時纔會發生,默認情況下有效激活「spring-configured」。請參閱Javadoc的 org.springframework.context.annotation.EnableLoadTimeWeaving瞭解有關引導加載時織入支持的代碼 備選方案的信息。

因此,在總結把<context:load-time-weaver />似乎真的如何定義一個bean與的LoadTimeWeaver的ID和掃描類路徑尋找像aop.xml文件的特殊文件,以確定是否AspectJ的應打開。要確保aspectJ被打開,當然確實需要設置aspectj-weaving="on",如果無論何種原因它無法打開aspectJ,它將在啓動時失敗,這正是你想要的。在我的網絡應用程序中,我有一個測試,我在Web應用程序啓動時運行,以確保aspectJ正在運行,如果它不是它抱怨。

+1

感謝您的長時間答覆。設置explizit aspetj-weaving =「on」沒有幫助。我也玩過aop.xml:沒有成功。它真的好像是一個問題。 – noCodeFound 2012-10-25 22:06:35

1

我在JUnit設置中遇到了同樣的問題,使用標準彈簧式儀器設置。 當使用WebSphereLoadTimeWeaver在WebSphere容器中運行相同的代碼時,沒有任何問題!

我的openJPA代碼是增強的構建時間。 我的@Configurable和其他一些方面完成加載時間。

我最好的猜測是openjpa繼承策略的增強隨後與LTW發生衝突,因此給我一些與@Configuarable結合的空指針問題。

JUNIT例

AbstactWhatEver X =新混凝土(); // @Configurable正在工作

AbstactWhatEver x = new Concrete(); x.callAnyMethod(); //在openjpa摘要上給出LTW問題,因此@Configurable不起作用

上面的示例在WEBSPHERE ENV中工作。

你有沒有解決過這個問題?

+0

對不起,我沒有解決它。 – noCodeFound 2014-10-26 10:59:19