2012-02-23 2 views
2

Я устанавливаю LTW с AspectJ и весной довольно быстро и успешно. Вот установка: 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" /> 

Моя служба, которая будет autowired к классу:

@Service 
public class MyService { 
} 

Родитель класса:

public class Bar { 
} 

Конфигурируемые класс, что autowires обслуживание и расширение Бар.

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

И просто класс, который получил Referance для родительского класса Bar:

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()); 
} 

Странно, не так ли?

Большое спасибо

С уважением,

Andreas

+0

Какие версии Java, AspectJ вы используете? – Ralph

+0

Я использую Java 1.6, aspectj 1.6.12 und Spring 3.1.0.RELEASE. – noCodeFound

+0

Кровавый ад, я тоже испытываю эту проблему. Я только что поднял эту проблему в своей JIRA вместе с воспроизводимым тестовым случаем: https://jira.spring.io/browse/SPR-12901 – bertie

ответ

1

У меня были проблемы в прошлом, когда я думал, что LTW был настроен, но это было не по причинам, которые я не совсем уверен. Таким образом, я теперь на 100% явным образом в своей конфигурации внесут следующие изменения в ваш файл конфигурации и посмотрю, все ли работает.

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

удалить <aop:aspectj-autoproxy /> из конфигурации не нужно вас есть LTW действительно работает.

Когда вы запускаете тестирование JUnit, вы передаете аргумент vm, чтобы сообщить JUnit, где агент LTW? Если нет, то у вас нет LTW.

Вот что документы говорят о <context:load-time-weaver />

Активизирует Spring LoadTimeWeaver для этого контекста приложения, доступного как боб с именем «loadTimeWeaver». Любой компонент, который реализует интерфейс LoadTimeWeaverAware, будет автоматически получать LoadTimeWeaver; например, поддержка бутстрапа JPA Spring. По умолчанию ткач определяется автоматически. По состоянию на Spring 2.5: обнаружение Sun GlassFish, OC4J Oracle, агента VM Spring и любого ClassLoader, поддерживаемого Spring's ReflectiveLoadTimeWeaver (например, TomcatInstrumentableClassLoader). Активация ткацкого процесса AspectJ задается с помощью простого флага (атрибут «аспектный ткацкий») с трансформатором класса AspectJ, зарегистрированным в Spring LoadTimeWeaver. AspectJ плетение будет активировано по умолчанию, если в пути к классам присутствует ресурс «META-INF/aop.xml». Это также активирует текущий контекст приложения для применения инъекции зависимостей к не управляемым классам, которые создаются вне фабрики весеннего компонента (обычно это аннотированные классы с @Configurable аннотацией). Это произойдет только в том случае, если объект AnnotationBeanConfigurerAspect находится в пути класса (т. Е. Spring-aspects.jar), эффективно активируя настройку «по-умолчанию» по умолчанию. См. Javadoc для org.springframework.context.annotation.EnableLoadTimeWeaving для получения информации о основанных на коде альтернативах загрузки загрузочного времени.

Таким образом, в итоге поставив <context:load-time-weaver />, кажется, на самом деле об определении боба с идентификатором loadTimeWeaver и сканированием класса пути ищет специальные файлы, такие как aop.xml, чтобы определить, является ли AspectJ должен быть включен. Чтобы убедиться, что aspectJ включен, наверняка вам действительно нужно установить aspectj-weaving="on" таким образом, если он не может включить aspectJ по какой-либо причине, он не сработает при запуске, который именно вы хотите. В моем веб-приложении у меня есть тест, который я запускаю при запуске веб-приложения, чтобы убедиться, что aspectJ запущен, и если он не жалуется.

+1

Спасибо за длинный ответ. Установка explizit aspetj-weaving = "on" не помогла. Я также играл с aop.xml: без успеха. Это действительно похоже на проблему с повышением. – noCodeFound

1

Я испытываю ту же проблему в настройке JUnit со стандартной установкой пружинного инструмента. При запуске одного и того же кода в контейнере WebSphere с WebSphereLoadTimeWeaver нет проблем, что так всегда!

Мой код openJPA увеличивает время сборки. My @Configurable и некоторые другие аспекты - это время загрузки.

Мое лучшее предположение заключается в том, что усиление стратегии наследования openjpa конфликтует позже с LTW и, следовательно, дает мне некоторые проблемы с нулевым указателем в сочетании с @Configuarable.

Junit ПРИМЕР

AbstactWhatEver х = новый Бетон(); // @Configurable работает

AbstactWhatEver x = new Concrete(); x.callAnyMethod(); // дает проблему LTW на openjpa abstract, следовательно @Configurable не работает

ОБА ВЫШЕ ПРИМЕРЫ РАБОТА В WEBSPHERE ENV.

Вы когда-нибудь решают эту проблему?

+0

Извините, нет, я не разрешил это. – noCodeFound

Смежные вопросы