[SPRING] 봄 XML 파일 구성 계층 도움말 / 설명

봄 XML 파일 구성 계층 도움말 / 설명

Spring에 대해 처음 배우기 시작했을 때, applicationContext.xml 파일에 구성되었습니다. 그런 다음 봄의 최신 버전에 대한 책을 읽기 시작하면서 myapp-servlet-xml, myapp-security.xml, myapp-service.xml 등과 같은 별도의 XML 파일로 구성을 완료했습니다. web.xml 파일에 contextConfigLocation을 구성합니다. 그래서, 예를 들어, 내가 함께 따라 왔던 코드는 contextConfigLocation과 같습니다.

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
        /WEB-INF/myapp-servlet.xml
        /WEB-INF/myapp-data.xml
    </param-value>
</context-param>

어쨌든, 최근에 저는이 분리로 인한 구성 문제 (StackOverflow의 도움이되는 사람들이 알아내는 데 도움이되었습니다)에 부딪혔습니다. 이 책의 예제에 대한 applicationContext.xml 파일은 없었으며 나중에 응용 프로그램에 자동 스캔 및 주석을 추가하려고 시도했을 때 문제가 발생했습니다. 나는 모든 것을 applicationContext.xml로 이동시키고 다른 파일들을 없애고 그 문제를 해결했다. 다른 것은 변하지 않았고 모든 것을 applicationContext.xml에 넣었습니다.

그래서, 다른 사람들의 의견과 함께 이것이 applicationContext.xml을 만들지 않아도 여전히 사용 중이며 일종의 구성 계층의 최상위 수준이라는 것을 알게되었습니다. 나는 다른 어떤 사람이 나에게 설명 할 수 있기를 바라고있다. 왜냐하면 나는 어디서나 그것에 대한 설명을 찾지 않았기 때문에이 모든 것이 어떻게 작동 하는지를 설명 할 수있다.

예를 들어 applicationContext.xml 아래에있는 구성 파일에 특정 컨텍스트 : 구성 요소 스캔 태그를 넣으면 특정 클래스가 검색되지 않을 수 있습니다. 그 자연의 것들. 우선 순위를 이해하지 못하고 무엇이 응용 프로그램 전반에 걸쳐 있는지 확인해야합니다. 누구든지 명확하게 설명 할 수 있거나 그것을 설명하는 자료를 알려 주면 고맙겠습니다. 감사합니다. 다행히도 내가 묻는 것은 의미가있다.

해결법

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

   1.Spring이 기본 설정 파일로 기대하는 이름 인 것을 제외하면 "applicationContext.xml"이라는 파일에는 특별한 것이 없다. "dog.xml", "cat.xml"및 "alien.xml"이라는 파일 하나 또는 여러 파일을 사용하면 똑같은 방식으로 작동합니다. 여러 개의 XML 파일을 가지고있는 것이 아니라 동시에 여러 ApplicationContext를 사용하면 문제가 발생합니다. 나는 최근에이 개념을 이해하지 못하여 문제가 발생한 사람들로부터 몇 가지 질문에 답했습니다. 이 답변을 확인하고 아직 어떤 질문이 있는지 확인하십시오.

   Spring이 기본 설정 파일로 기대하는 이름 인 것을 제외하면 "applicationContext.xml"이라는 파일에는 특별한 것이 없다. "dog.xml", "cat.xml"및 "alien.xml"이라는 파일 하나 또는 여러 파일을 사용하면 똑같은 방식으로 작동합니다. 여러 개의 XML 파일을 가지고있는 것이 아니라 동시에 여러 ApplicationContext를 사용하면 문제가 발생합니다. 나는 최근에이 개념을 이해하지 못하여 문제가 발생한 사람들로부터 몇 가지 질문에 답했습니다. 이 답변을 확인하고 아직 어떤 질문이 있는지 확인하십시오.

   부모 컨텍스트에서 자식 컨텍스트와 스프링 컨텍스트 선언

   Spring-MVC : "컨텍스트"와 "네임 스페이스"란 무엇입니까?

   수정 : 귀하의 새 질문에 대한 응답으로 :

   이 "servlet.xml"파일의 이름은 foo-servlet.xml과 같으며 web.xml에 구성된 DispatcherServlet의 이름은 "foo"입니다.

   <servlet>
       <servlet-name>foo</servlet-name>
       <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   </servlet>
   

   규약에 따라이 DispatcherServlet이 시작되면 servlet-name에서 파생 된 foo-servlet.xml 파일로 구성된 새 ApplicationContext가 만들어집니다. 컨텍스트 : component-scan을 거기에 넣으므로, 주어진 패키지를 반복적으로 스캔하고 모든 주석이 달린 클래스에 대한 빈을 생성합니다. 여러분이 제공 한 패키지 인 com.myapp는 전체 앱의 기본 패키지 인 것처럼 보이므로 Spring은 데이터 액세스 객체를 포함하여 응용 프로그램의 주석이 달린 모든 클래스에서 Bean을 생성합니다.이 Bean은 해당 DispatcherServlet. 일반적으로이 컨텍스트에는 DispatcherServlet을 직접 지원하는 뷰 계층 항목과 Bean 만 있어야하므로 잘못 구성된 것입니다.

   아마도이 "data.xml"파일은 contextConfigLocation context-param에 나열한 파일 일 것입니다. ContextLoaderListener를 web.xml에 추가했다고 가정합니다.

   <listener>
       <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
   

   이 파일은 루트 컨텍스트 인 두 번째 ApplicationContext를 만드는 데 사용됩니다. 그것이 청취자가하는 것입니다. contextConfigLocation에 나열된 모든 파일의 컨텍스트를 실제로 작성하고, 해당 목록에 "servlet.xml"을 포함시킨 경우 해당 컨텍스트를 두 번로드합니다. 여기서 컨텍스트와 루트 컨텍스트 DipatcherServlet과 연관되어 있습니다. 다행히 XML 구성 파일과 구성하는 ApplicationContext간에 명확한 구분이있는 방법을 살펴 보시기 바랍니다. 동일한 XML 파일을 사용하여 두 개의 서로 다른 컨텍스트를 쉽게 구성 할 수 있습니다. 그렇게하는 것이 맞는지 아닌지는 또 하나의 질문입니다. 이 특별한 경우에는 그렇지 않습니다.

   이 두 문맥을 설명한 순서는 실제로 거꾸로입니다. 네가 한 일에 대한 너의 묘사를 따랐을 뿐이야. ServletContextListener 인 ContextLoaderListener는 서블릿이 시작되기 전에 항상 실행됩니다. 즉, 루트 컨텍스트가 먼저 생성되고 다른 컨텍스트가 생성됩니다. DispatcherServlet이 컨텍스트를 만들 때 해당 컨텍스트를 루트 컨텍스트의 자식으로 추가 할 수 있도록 설계된 것입니다. 나는 다른 포스트들에서이 관계를 묘사했다. 가장 중요한 영향은 루트 컨텍스트의 Bean이 DispatcherServlet의 컨텍스트를 통해 사용할 수 있다는 것입니다. autowired 관계에도 적용됩니다. DispatcherServlet은 제어기 인스턴스와 같이 필요한 빈에 대해서만 관련 컨텍스트를 조사하기 때문에 중요합니다. 컨트롤러는 분명히 지원하는 빈들과 연결되어야합니다. 따라서 전통적으로 컨트롤러는 DispatcherServlet의 컨텍스트에 있고 지원하는 Bean은 루트 컨텍스트에 있습니다.

   @Transactional이 작동하려면 태그를 주석 처리 된 bean이있는 ApplicationContext 구성에 포함시켜야합니다. 트릭은 "그것이 사는 곳"부분을 파악하는 것입니다. 하위 Bean은 상위 컨텍스트의 Bean을 대체 할 수 있습니다. 따라서 여기에서 짐작할 것입니다. 위에서 설명한 것처럼 모든 빈을 DispatcherServlet 컨텍스트에로드했지만 루트 컨텍스트에 를 넣으면 루트 컨텍스트에 빈을 가질 수 있습니다 그것은 정확하게 트랜잭션 적이지만, 복제본이 부모 / 자식 계층의 서블릿에 "더 가깝기"때문에 사용되는 것이 아니며 컨텍스트가 구성을 갖지 않았기 때문에 사용되는 것이 아닙니다.

   여전히 당신이 어떤 ApplicationContexts에 어떤 설정 파일을 포함 시켰는가에 달려 있지만 적어도 이렇게하면 문제를 일으키는 DispatcherServlet 컨텍스트에서 많은 빈을 제거했다고 말할 수 있습니다. 특히 루트 컨텍스트의 올바르게 구성된 @Transactional Bean은 하위 컨텍스트의 Bean에 의해 더 이상 섀도 잉되지 않으며 컨트롤러에 주입되므로 지속성 항목이 작동합니다.

   그래서 ... 두 가지 관련 ApplicationContext가 있다는 점을 빼앗아 야합니다. 당신은 그 사실을 알고 있어야하고 콩이 어떤 상황에 있는지를 통제해야합니다.

   그것은 모든 것을 다 커버합니까?

from https://stackoverflow.com/questions/7774295/spring-xml-file-configuration-hierarchy-help-explanation by cc-by-sa and MIT license