Spring 3 Проблемы компиляции времени компиляции для объектов в зависимости от jar с @Configurable (с использованием Maven) - PullRequest
Новая
       20

Spring 3 Проблемы компиляции времени компиляции для объектов в зависимости от jar с @Configurable (с использованием Maven)

2 голосов
/ 16 февраля 2012

Гуглил и работал над этим слишком долго. Перебирал также и другие сообщения от stackoverflow, но все же был озадачен тем, что здесь происходит.

Прежде всего, что я хочу:

У меня есть постоянный фляга, которая используется в качестве зависимости в моем веб-проекте. В этом банке персистентности даос настроен просто отлично, используя конфигурацию Spring из веб-проекта. То, что я хочу сделать сейчас, это базовый класс (абстрактный). Я хочу иметь возможность внедрить набор свойств в строку, но классы, расширяющие этот абстрактный класс, напрямую не контролируются через Spring (например, создается с помощью нового MyImp ().)

Из всего, что я собираю, мне нужно будет использовать @ Configurable .

Странно то, что код все компилируется (с Maven, использующим плагин аспектов), и я думаю, что должно происходить некоторое переплетение, потому что вызовы объектов, расширяющих абстрактный класс @Configurable, похоже, попадают в «черную дыру» - никаких ошибок пока ничего не может быть напечатано в системе через старые инструкции skool System.out.print ??? Действительно странно.

Ниже, я думаю, приведена соответствующая информация о том, как у меня все настроено ... (очевидно, не все показывает):

Конфигурация пружины веб-проекта: 

<util:properties id="props" location="classpath:application.properties"/>

<context:annotation-config />
<context:spring-configured/>
<context:component-scan base-package="com.foo" />

<bean class="com.foo.MyAbstractClass" abstract="true" scope="prototype">
    <property name="xlsDir" value="${xlsDir}"/>
</bean> 

//some DAOs are injected with datasources..not shown. Props being set just fine for the 
//datasources from application.properties, and the DAOs will work fine

Jar, используемый вышеупомянутым веб-проектом (который содержит MyAbstractClass и его потомков), не имеет никакого XML. Различные файлы расширяют MyAbstractClass и создаются в приложении с помощью нового: MyImp imp = new MyImp (); imp.bar ();

MyAbstractClass соответствующая информация: 

@Configurable
public abstract class MyAbstractClass {
    private String xlsDir;

    public void setXlsDir(String xlsDir) {
        this.xlsDir = xlsDir;
     }  

    public void bar() {
        System.out.println("this won't even get printed, yet no errors!");
        System.out.println("xlsDir is "+xlsDir);
     }
 }

Я могу поиграться с @Autowiring позже и с помощью @Value (это то, что я впервые попробовал в любом случае), но сейчас я даже не уверен, что ткачество работает правильно. Может быть, проблема в том, что jar-файл персистентности сначала компилируется через maven (с ткачеством) - но пока он не знает, что такое установщик для xlsDir, на основе веб-проекта? Однако это не объясняет, почему вызовы bar () просто исчезают, поэтому что-то происходит.

Для обоих проектов я настроил maven для компиляции на основе того, что я видел, когда Pom Spring Roo делал (в Интернете очень сложно найти то, что нужно в этом pom для ткачества maven с пружиной.)

Вот соответствующая информация о помпе (комментарии оставленной весной руо ниже - они не мои): 

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>aspectj-maven-plugin</artifactId>
    <version>1.2</version> <!-- NB: do use 1.3 or 1.3.x due to MASPECTJ-90 - wait for 1.4 -->
    <dependencies>
        <!-- NB: You must use Maven 2.0.9 or above or these are ignored (see 
            MNG-2972) -->
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${aspectj.version}</version>
        </dependency>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjtools</artifactId>
            <version>${aspectj.version}</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <outxml>true</outxml>
        <aspectLibraries>
            <aspectLibrary>
                <groupId>org.springframework</groupId>
                <artifactId>spring-aspects</artifactId>
            </aspectLibrary>
        </aspectLibraries>
        <source>1.6</source>
        <target>1.6</target>
    </configuration>
</plugin>

<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjrt</artifactId>
    <version>${aspectj.version}</version>
</dependency>
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>${aspectj.version}</version>
</dependency> 
 <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aspects</artifactId>
    <version>${spring.version}</version>
</dependency> 
 <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-aop</artifactId>
    <version>${spring.version}</version>
</dependency>

Любая помощь высоко ценится. Я собираюсь скоро сдаться и просто загрузить свой файл свойств в статический блок и покончим с этим :)

1 Ответ

0 голосов
/ 17 февраля 2012

Определение компонента 

<bean class="com.foo.MyAbstractClass" abstract="true" scope="prototype">
    <property name="xlsDir" value="${xlsDir}"/>
</bean>

ничего не делает, если не используется как родительский в других определениях компонентов.Если вы хотите, чтобы bean-компоненты @Configurable стали автоматически подключенными, используйте @Configurable (autowire = Autowire.BY_NAME) и объявите бин String с name = "xlsDir" 

<bean id="xlsDir" class="java.lang.String" factory-method="valueOf">
    <constructor-arg value="${xlsDir}"/>
 </bean>
...