Issue 1:
Stepan Koltsov opened SPR-8719 and commented

@ComponentScan does not work in @Import-ed configuration.

public class Coin { }

public class Main {

@Configuration
@ComponentScan(basePackageClasses = Main.class,
useDefaultFilters = false,
includeFilters = @ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, value = Coin.class))
public static class Conf1 {
}

@Configuration
@Import(Conf1.class)
public static class Conf2 {

}

public static void main(String[] args) {
System.out.println("loading Conf1"); // works fine
new AnnotationConfigApplicationContext(Conf1.class).getBean(Coin.class);

System.out.println("loading Conf2"); // cannot find a bean
new AnnotationConfigApplicationContext(Conf2.class).getBean(Coin.class);
System.out.println("Unreachable in Spring 3.1.0.M2");
}

}

Outputs:

loading Conf1
loading Conf2
Exception in thread "main" org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [ru.yandex.commune.junk.stepancheg.spring.shinderuk.Coin] is defined: expected single bean but found 0:
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:269)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1101)
at ru.yandex.commune.junk.stepancheg.spring.shinderuk.Main.main(Main.java:31)

Probably related to #12956.

Affects: 3.1 M2

Issue Links:

#13670 @ComponentScan with includeFilters on @Import-ed context does not work ("duplicates")

#12634 @ComponentScan does not work when referenced from XML config ("is duplicated by")

#13738 ClassPathBeanDefinitionScanner vs ClassPathBeanDefinitionScanner: difference in behavior when dealing with @ComponentScan excludeFilters

Referenced from: commits d9f7fdd

2 votes, 0 watchers

Issue 2:
Jon Are Storløkken opened SPR-2877 and commented

This is mainly a documentation issue. (Although it would be possible to improve on the design as well)

The problem is the org.springframework.scheduling.quartz.JobDetailBean. It should be clearly stated that this bean cannot be used with a persistent job store. This is such an important issue when using Quartz, that it should be mentioned explicitly. Among other things, a persistent job store is required when running Quartz in a cluster. This is a very common requirement in enterprise applications, and JobDetailBean is therefore not very useful for most applications.

My problem actually stems from using code copied from the book ProSpring (p 513) by Rob Harrop, where he shows an example of using JobDetailBean with a persistent job store. Clearly, this config has never been tested. This is a widely read book (by an Interface21 guy AFAIK), and this config will be widely read and copied.

In my opinion the code could be improved:

The problem stems from JobDetail bean being ApplicationContextAware, which it needn't be. (It puts the applicationContext in the jobDataMap) SchedulerFactory puts the applicationContext in the schedulerContext anyway, why can not the Job get the applicationContext from there?

See this thread for some further info:

http://forum.springframework.org/showthread.php?t=31820

Affects: 1.2.8, 2.0.1

Issue Links:

#7537 Upgrade to Quartz 1.6.1 (for trigger persistence with SimpleTriggerBean and CronTriggerBean) ("duplicates")

1 votes, 1 watchers