un peu sur ApplicationContext Hiérarchies

---

Ressort ApplicationContext fournit la possibilité de charger plusieurs contextes (hiérarchiques), permettant à chacun d'être concentré sur une couche particulière, telle que la couche web d'une application ou des services de niveau intermédiaire.

un des exemples canoniques d'utilisation de ApplicationContext c'est quand nous avons plusieurs DispatcherServlet s dans une application web et nous allons partager certains des haricots communs tels que datasources entre eux. De cette façon, nous pouvons définir une racine ApplicationContext qui contiennent tous les haricots communs et plusieurs WebApplicationContext s qui héritent les haricots communs du contexte de la racine.

Dans le Web framework MVC, chaque DispatcherServlet a son propre WebApplicationContext, qui hérite de tous les grains déjà définis dans la racine WebApplicationContext. Ces fèves héritées peuvent être supplantées dans la portée spécifique à une portion, et vous pouvez définir de nouvelles fèves spécifiques à une portion donnéeServlet instance.

^{Typique contexte de hiérarchie dans Web Spring MVC (Printemps Documentation)}

si vous vivez seul DispatherServlet monde, il est également possible d'avoir un seul contexte de la racine pour ce scénario:

^{contexte de racine simple dans le Web de printemps MVC (printemps La Documentation)}

parler c'est pas cher, Montrez-moi le code!

---

supposons que nous développions une application web et que nous utilisions Spring MVC, Spring Security et Spring Data JPA. Pour ce scénario simple, nous aurions au moins trois fichiers de configuration différents. WebConfig qui contient toutes nos configurations liées au web, comme ViewResolver s,Controller s,ArgumentResolver s, etc. Quelque chose comme suit:

@EnableWebMvc
@Configuration
@ComponentScan(basePackages = "com.so.web")
public class WebConfig extends WebMvcConfigurerAdapter {
    @Bean
    public InternalResourceViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/views/");
        viewResolver.setSuffix(".jsp");

        return viewResolver;
    }

    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        final boolean DO_NOT_USE_SUFFIX_PATTERN_MATCHING = false;
        configurer.setUseSuffixPatternMatch(DO_NOT_USE_SUFFIX_PATTERN_MATCHING);
    }
}

Ici je suis la définition d'un ViewResolver pour résoudre mes vieux jsps, de mauvaises décisions de vie, en gros. Nous aurions besoin d'un RepositoryConfig, qui contient toutes les facilités d'accès aux données telles que DataSource,EntityManagerFactory,TransactionManager, etc. Il serait sans doute comme suit:

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(basePackages = "com.so.repository")
public class RepositoryConfig {
    @Bean
    public DataSource dataSource() { ... }

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() { ... }

    @Bean
    public PlatformTransactionManager transactionManager() { ... }
}

Et SecurityConfig qui contient tous les trucs liés à la sécurité!

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    @Autowired
    protected void configure(AuthenticationManagerBuilder auth) throws Exception { ... }

    @Override
    protected void configure(HttpSecurity http) throws Exception { ... }
}

pour coller tout cela ensemble, nous avons deux options. Tout d'abord, on peut définir une typique hiérarchique ApplicationContext, en ajoutant RepositoryConfig et SecurityConfig dans le contexte de la racine et WebConfig dans le contexte de leur enfant:

public class ServletInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class<?>[] { RepositoryConfig.class, SecurityConfig.class };
    }

    @Override
    protected Class<?>[] getServletConfigClasses() {
        return new Class<?>[] { WebConfig.class };
    }

    @Override
    protected String[] getServletMappings() {
        return new String[] { "/" };
    }
}

Depuis que nous avons un seul DispatcherServlet ici, on peut ajouter le WebConfig au contexte root et vider le contexte servlet:

public class ServletInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
    @Override
    protected Class<?>[] getRootConfigClasses() {
        return new Class<?>[] { RepositoryConfig.class, SecurityConfig.class, WebConfig.class };
    }

    @Override
    protected Class<?>[] getServletConfigClasses() {
        return null;
    }

    @Override
    protected String[] getServletMappings() {
        return new String[] { "/" };
    }
}

Autres Lectures

---

Skaffman a fait du bon travail en expliquant ApplicationContext hiérarchies dans ce réponse, ce qui est fortement recommandé. Aussi, vous pouvez lire Documentation De Printemps.