[SPRING] AbstractAnnotationConfigDispatcherServletInitializer를 확장 할 때 getServletConfigClasses ()와 getRootConfigClasses () 비교

AbstractAnnotationConfigDispatcherServletInitializer를 확장 할 때 getServletConfigClasses ()와 getRootConfigClasses () 비교

AbstractAnnotationConfigDispatcherServletInitializer를 확장 할 때 getServletConfigClasses ()와 getRootConfigClasses ()의 차이점은 무엇입니까? 나는 오늘 아침 이후로 많은 출처를 읽었지 만, 아직 차이점에 대한 명확한 이해를 얻지 못했습니다 :

다음 두 가지 구성을 살펴보십시오.

1).

public class SpringMvcInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

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

ConServlet.class는 다음을 참조합니다.

@EnableWebMvc 
@Configuration
@ComponentScan({ "com" })
@Import({ SecurityConfig.class })
public class ConServlet {
    @Bean
    public InternalResourceViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setViewClass(JstlView.class);
        viewResolver.setPrefix("/WEB-INF/pages/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }   
}

2).

public class WebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

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

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

Web Config.class는 다음을 참조합니다.

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = { "....." })
public class WebConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/resources/**").addResourceLocations("/resources/");
    }

    @Bean
    public ViewResolver viewResolver() {

        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setViewClass(JstlView.class);
        viewResolver.setPrefix("/WEB-INF/views");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }
}

ConServlet & Web Config (어느 정도)는 뷰 초기화와 같은 일을합니다.

그러나 왜 :

나는 문서를 읽었다.

getRootConfigClasses () 및 getServletConfigClasses () 모두에 대한

하지만 ConServlet과 WebConfig가 같은 일을하고있는 이유는 (예를 들어, initizialising view와 같은) 어쩌면 내가 오해 한 것일 수도 있습니다. 간단한 용어 / 예제에서 실제로 루트 컨텍스트와 디스패처 서블릿 (이 것을 알고 있음)은 무엇입니까?

고맙습니다!

해결법

1. ==============================

   1.Spring의 ApplicationContext는 다중 (계층 적) 컨텍스트를 로딩 할 수있는 기능을 제공하며, 각 컨텍스트는 애플리케이션의 웹 레이어 또는 중간 계층 서비스와 같은 특정 레이어에 집중할 수 있습니다.

   Spring의 ApplicationContext는 다중 (계층 적) 컨텍스트를 로딩 할 수있는 기능을 제공하며, 각 컨텍스트는 애플리케이션의 웹 레이어 또는 중간 계층 서비스와 같은 특정 레이어에 집중할 수 있습니다.

   계층 적 ApplicationContext를 사용하는 표준적인 예 중 하나는 웹 애플리케이션에 여러 DispatcherServlet이 있고 그 사이에 데이터 소스와 같은 일부 공통 Bean을 공유 할 때입니다. 이 방법으로 모든 공통 빈과 루트 컨텍스트에서 공통 빈을 상속받는 여러 WebApplicationContext를 포함하는 루트 ApplicationContext를 정의 할 수있다.

   웹 MVC 프레임 워크에서 각 DispatcherServlet에는 루트 WebApplicationContext에 이미 정의 된 모든 Bean을 상속하는 고유 한 WebApplicationContext가 있습니다. 이러한 상속 된 Bean은 서블릿 특정 범위에서 재정의 될 수 있으며 특정 Servlet 인스턴스에 대해 새로운 범위 별 Bean을 정의 할 수 있습니다.

   스프링 웹 MVC (Spring Documentation)의 일반적인 컨텍스트 계층 구조

   단일 DispatherServlet 환경에 살고 있다면이 시나리오에 대해 하나의 루트 컨텍스트를 가질 수도 있습니다.

   스프링 웹 MVC (Spring Documentation)의 단일 루트 컨텍스트

   웹 애플리케이션을 개발 중이며 Spring MVC, Spring Security 및 Spring Data JPA를 사용한다고 가정합니다. 이 간단한 시나리오의 경우 최소한 세 가지 설정 파일이 필요합니다. ViewResolvers, Controllers, ArgumentResolvers 등과 같은 우리의 모든 웹 관련 구성을 포함하는 WebConfig 다음과 같은 것 :

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

   여기에서는 기본적으로 저의 오래된 jsp, 가난한 삶의 결정을 해결하기 위해 ViewResolver를 정의하고 있습니다. DataSource, EntityManagerFactory, TransactionManager 등과 같은 모든 데이터 액세스 기능을 포함하는 RepositoryConfig가 필요할 것입니다. 아마도 다음과 같을 것입니다.

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

   그리고 모든 보안 관련 내용을 담고있는 SecurityConfig!

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

   이 모든 것을 함께 붙이기 위해 두 가지 옵션이 있습니다. 먼저 루트 컨텍스트에 RepositoryConfig와 SecurityConfig를 추가하고 자식 컨텍스트에 WebConfig를 추가하여 일반적인 계층 적 ApplicationContext를 정의 할 수 있습니다.

   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[] { "/" };
       }
   }
   

   여기에 하나의 DispatcherServlet이 있기 때문에 Web Config를 루트 컨텍스트에 추가하고 서블릿 컨텍스트를 비워 둘 수 있습니다.

   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[] { "/" };
       }
   }
   

   Skaffman은이 답변에서 ApplicationContext 계층 구조를 설명하는 데 큰 도움이되었습니다. 또한 스프링 문서를 읽을 수 있습니다.

2. ==============================

   2.루트 구성 클래스는 실제로 Application Specific이고 Filters에 사용할 수 있어야하는 Bean을 생성하는 데 사용됩니다 (Fillet은 Servlet의 일부가 아닙니다).

   루트 구성 클래스는 실제로 Application Specific이고 Filters에 사용할 수 있어야하는 Bean을 생성하는 데 사용됩니다 (Fillet은 Servlet의 일부가 아닙니다).

   서블릿 구성 클래스는 실제로 ViewResolvers, ArgumentResolvers, Interceptor 등과 같은 DispatcherServlet에 특정한 Bean을 생성하는 데 사용됩니다.

   루트 구성 클래스가 먼저로드 된 다음 서블릿 구성 클래스가로드됩니다.

   루트 구성 클래스는 상위 컨텍스트가되며 ApplicationContext 인스턴스를 만듭니다. 서블릿 구성 클래스가 상위 컨텍스트의 하위 컨텍스트 일 ​​때 WebApplicationContext 인스턴스를 생성합니다.

   ConServlet 구성에서 @EnableWebMvc와 WebConfig에서만 필요하기 때문에 InternalResourceViewResolver 빈을 지정할 필요가 없습니다.

from https://stackoverflow.com/questions/35258758/getservletconfigclasses-vs-getrootconfigclasses-when-extending-abstractannot by cc-by-sa and MIT license