설정관리 스케줄 JOB 현황 문의.(2)
- 작성자 :
- 정*진
- 작성일 :
- 2011-05-17 09:35:20
- 조회수 :
- 2,219
- 구분 :
- 공통컴포넌트
- 진행상태 :
- 완료
Q
보내주신 답변 내용 잘 봤습니다.
그런데요... 제가 설명이 부족했던거 같은데요...
sms.war 파일을 기존의 프로젝트에 디플로이해서 사용할려고 하구요,
egovsms.properties의 xml*path는 기존 프로젝트의 resources/spring/ 경로로 했습니다.
결국, context-scheduler.xml 파일이 기존 프로젝트에 위치하게 도구요, <bean id="SchedulerFactory" /> 역시도 위의 xml파일에서 확인했구요.... 그런데 bean을 못 찾는다고 나오네요...
혹시, 배포된 war파일의 WebApplicationContext가 기존 프로젝트의 WebApplicationContext의 bean을 못 읽는 구성이어서 그런건 아닌지요? war를 다른 프로젝트에 배포시 설정할게 없는지요?
그런데요... 제가 설명이 부족했던거 같은데요...
sms.war 파일을 기존의 프로젝트에 디플로이해서 사용할려고 하구요,
egovsms.properties의 xml*path는 기존 프로젝트의 resources/spring/ 경로로 했습니다.
결국, context-scheduler.xml 파일이 기존 프로젝트에 위치하게 도구요, <bean id="SchedulerFactory" /> 역시도 위의 xml파일에서 확인했구요.... 그런데 bean을 못 찾는다고 나오네요...
혹시, 배포된 war파일의 WebApplicationContext가 기존 프로젝트의 WebApplicationContext의 bean을 못 읽는 구성이어서 그런건 아닌지요? war를 다른 프로젝트에 배포시 설정할게 없는지요?
A
안녕하세요.. 정영진님..
개발하시는 프로젝트에 설정관리를 포함하셨다는 의미는..
설정관리의 설정들을 기존 프로젝트의 설정(web.xml에 기술된 contextConfigLocation 2개 부분)에 포함시키셨기 때문에.. context-scheduler.xml에 정의된 bean을 못찾는 경우는 없을 것 같습니다.
배포된 war도 자체적으로 ApplicationContext를 기동하는 방식이 아니라.. web.xml 기술된 ContextLoaderListener나 DispatcherServlet에 의해 기동되는 ApplicationContext에 의해 호출되도록 되어 있습니다.
기존 프로젝트 web.xml의 ContextLoaderListener 부분의 contextConfigLocation 지정에 context-scheduler.xml가 포함되는지 다시 한번 확인 부탁드립니다.
그럼.. 즐거운 하루되십시오.
감사합니다.
개발하시는 프로젝트에 설정관리를 포함하셨다는 의미는..
설정관리의 설정들을 기존 프로젝트의 설정(web.xml에 기술된 contextConfigLocation 2개 부분)에 포함시키셨기 때문에.. context-scheduler.xml에 정의된 bean을 못찾는 경우는 없을 것 같습니다.
배포된 war도 자체적으로 ApplicationContext를 기동하는 방식이 아니라.. web.xml 기술된 ContextLoaderListener나 DispatcherServlet에 의해 기동되는 ApplicationContext에 의해 호출되도록 되어 있습니다.
기존 프로젝트 web.xml의 ContextLoaderListener 부분의 contextConfigLocation 지정에 context-scheduler.xml가 포함되는지 다시 한번 확인 부탁드립니다.
그럼.. 즐거운 하루되십시오.
감사합니다.
