SG Dev

JSF 라이프 사이클의 상세 설명

이전 블로그 글에서 본 라이프 사이클 이미지를 보면서 각 단계(phase)에 대하여 상세 설명을 하도록 하겠습니다.

JSF 라이프 사이클

JSF 어플리케이션 라이프 사이클의 실행(execute) 단계는 다음의 하위 단계를 포함합니다.

• 뷰 복원 단계 (Restore View Phase)
• 요청 값 적용 단계 (Apply Request Values Phase)
• 검증 처리 단계 (Process Validations Phase)
• 모델 값 업데이트 단계 (Update Model Values Phase)
• 어플리케이션 호출 단계 (Invoke Application Phase)
• 응답 랜더링 단계 (Render Response Phase)

뷰 복원 단계 (Restore View Phase)

JSF 페이지에 대한 요청이 발생 할때 그리고 링크 또는 버튼 컴포넌트를 클릭하는 액션에 의해 JSF 구현은 뷰 복원 단계를 시작합니다.

이 단계에서 JSF 구현은 컴포넌트와 연결된 이벤트 처리기(handler)와 검증기(validator)가 포함된 뷰를 빌드 하여 FacesContext 인스턴스에 저장하는데 이 뷰에는 하나의 요청을 처리하는데 필요한 모든 정보가 포함 되어 있습니다. 모든 어플리케이션 컴포넌트의 이벤트 처리기, 변환기 그리고 검증기는 FacesContext 인스턴스에 접근할 수 있습니다.

만약 페이지 요청이 초기 요청(initial request)일 경우 JSF 구현은 이 단계에서 비어 있는 뷰(view)를 만들고 응답 랜더링 단계(Render Response Phase)로 진행 하는 동안 비어있는 뷰에는 페이지에 있는 태그를 참고 하여 컴포넌트들을 채우게 됩니다. 여기서 페이지는 개발자가 직접 태그를 이용하여 만든 xhtml 페이지 입니다.

만약 페이지에 대한 요청이 포스트백인 경우 이 페이지에 해당하는 뷰는 이미 FacesContext 인스턴스에 존재 합니다. 이때 JSF 구현은 클라이언트 또는 서버에 이미 저장되어 있는 상태 정보를 이용하여 뷰를 복원 합니다.

요청 값 적용 단계 (Apply Request Values Phase)

컴포넌트 트리가 포트스백 요청시 복원이 된 후에 트리의 각 컴포넌트는 디코드(processDocodes()) 메소드를 사용하여 요청 파라메터(request parameters)에서 새로운 값을 추출(extract) 합니다.

만약 디코드 메소드 또는 이벤트 리스너가 현재의 FacesContext 인스턴스에서 renderResponse 메소드를 호출하게 되면 JSF 구현은 응답 랜더링 단계로 건너 뜁니다.

이 단계에서 모든 이벤트가 대기(queued)중인 경우 JSF 구현은 관련 있는 이벤트 리스너에게 전달(broadcast) 합니다.

몇몇 컴포넌트들의 immediate 속성에 true 값이 설정되면 이 컴포넌트와 관련된 검증(validate), 변환(convet), 이벤트는 이 단계에서 처리됩니다. 만약 변환(conversion) 에 오류가 발생하면 해당 컴포넌트와 관련된 오류 메세지가 생성되고 FacesContext 에 대기(queue)합니다. 이 메세지는 검증 단계의 처리중 발생한 모든 검증 오류의 결과와 함께 응답 랜더링 단계(Render Response Phase)에서 표시됩니다.

이때 만약 어플리케이션이 다른 웹 어플리케이션 리소스로 리디렉션(redirect)이 필요하거나 JSF 컴포넌트를 포함하지 않는 응답을 생성할 경우 FacesContext.responseComplete 메소드를 호출 할 수 있습니다.

이 단계의 마지막에 컴포넌트는 새로운 값으로 설정되고 메세지와 이벤트가 대기(queue)하고 있습니다.

만약 현재 요청이 partial 요청으로 식별 될 경우 partial context 는 FacesContext 에서 검색되고 partial 처리 메소드가 적용 됩니다.

검증(유효성) 처리 단계 (Process Validation Phase)

이 단계에서 JSF 구현은 검증(processValidator) 메소드를 통해 뷰 트리의 컴포넌트에 등록된 모든 검증기(validator)를 처리 합니다. 그것은 컴포넌트의 속성들을 검사하는데 검증을 위한 규칙을 명확하게 하고 그 규칙은 컴포넌트에 저장된 로컬 값을 비교 합니다. JSF 구현은 또한 immediate 속성에 true 값이 설정 되지 않은 입력 컴포넌트의 변환(conversion)을 완료한다.

만약 로컬 값이 잘못되거나 모든 변환(conversion)이 실패하면 JSF 구현은 FacesContext 인스턴스에 오류 메세지를 추가하고 라이프 사이클은 응답 랜더링 단계로 곧장 이동하고 페이지는 오류 메세지를 다시 랜더링 합니다.

로컬값이 잘못되거나 변환(conversion)이 실패하면 JSF 구현은 FacesContext 에 오류 메세지를 추가하고 페이지가 오류 메세지를 다시 랜더링 할 수 있게 응답 랜더링 단계로 바로 이동합니다. 만약 변환 오류가 요청값 적용 단계(Apply Request Values Phase)에서 발생 할 경우 그 에러 메세지 또한 함께 표시됩니다.

만약 검증 메소드 또는 이벤트 리스너가 현재의 FacesContext 에서renderResponse 메소드를 호출하면 JSF 구현은 응답 랜더링 단계로 건너 뜁니다.

요청값 적용 단계에서 처럼 만약 어플리케이션이 다른 웹 어플리케이션 리소스로 리디렉션이 필요하거나 JSF 컴포넌트를 포함하지 않는 응답을 생성(generate) 할 경우 FacesContext.responseComplete 메소드를 호출 할 수 있습니다.

만약 이벤트가 이 단계동안 대기 하고 있으면 JSF 구현은 관련된 리스너로 전달 할 수 있습니다.

현재 요청이 partial 요청으로 식별 될 경우 partial context 는 FacesContext 에서 검색되고 partial 처리 메소드가 적용 됩니다.

모델 값 업데이트 단계 (Update Model Values Phase)

JSF 구현은 데이터가 유효한것으로 검증한 후 컴포넌트 트리에 있는 모든 컴포넌트의 로컬 값을 서버측(server-side) 객체의 구성요소에 설정합니다. JSF 구현은 오직 입력 컴포넌트의 속성(attribute) 값이 가리키는 빈(bean)의 구성요소(property)를 업데이트 합니다. 만약 로컬 데이터를 빈(bean) 구성요소에 의해 지정된 타입으로 변환(convert) 할 수 없는 경우에 라이프 사이클은 오류를 표시하는 페이지를 다시 랜더링 하기 위해 응답 랜더링 단계로 바로 진행합니다. 이것은 검증(validation) 오류가 발생하는 것과 동일합니다.

만약 updateModels 메소드 또는 리스너가 현재의 FacesContext 인스턴스의 renderResponse 메소드를 호출하면 JSF 구현은 응답 랜더링 단계로 건너 뜁니다.

이때 만약 어플리케이션이 다른 웹 어플리케이션 리소스로 리디렉션(redirect)이 필요하거나 JSF 컴포넌트를 포함하지 않는 응답을 생성할 경우 FacesContext.responseComplete 메소드를 호출 할 수 있습니다.

만약 이벤트가 이 단계동안 대기 하고 있으면 JSF 구현은 관련된 리스너로 전달 할 수 있습니다.

현재 요청이 partial 요청으로 식별 될 경우 partial context 는 FacesContext 에서 검색되고 partial 처리 메소드가 적용 됩니다.

어플리케이션 호출 단계 (Invoke Application Phase)

이 단계에서 JSF 구현은 폼 제출(submit a form) 또는 다른 페이지로 연결(linking)과 같은 어플리케이션 수준의 이벤트를 처리합니다.

이때 만약 어플리케이션이 다른 웹 어플리케이션 리소스로 리디렉션(redirect)이 필요하거나 JSF 컴포넌트를 포함하지 않는 응답을 생성할 경우 FacesContext.responseComplete 메소드를 호출 할 수 있습니다.

뷰(view)가 이전 요청의 상태 정보로 부터 재구성하는 처리를 하고 컴포넌트가 이벤트를 발생시키면 그 이벤트는 관련된 리스너로 전달이 됩니다.

마지막으로 JSF 구현은 응답 랜더링 단계로 제어를 전달합니다.

응답 랜더링 단계 (Render Response Phase)

이 단계에서 JSF는 뷰를 생성(build) 하고 페이지를 랜더링 하기 위해 적당한 리소스에 권한을 위임 합니다.

만약 초기 요청(initial request)이면 페이지페 표시될 컴포넌트를 컴포넌트 트리에 추가 합니다. 만약 초기 요청이 아니면 컴포넌트는 이미 트리에 추가 되어 있고 다시 추가될 필요는 없습니다.

만약 포스트백 요청이고 오류가 요청값 적용 단계, 검증 처리 단계, 모델 값 갱신 단계중 발생된 경우 오리지널 페이지는 이 단계에서 다시 랜더링 합니다. 만약 페이지에 h:message 또는 h:messages 태그가 있는 경우 대기중인 모든 오류 메세지가 페이지에 나타납니다.

뷰의 내용들이 랜더링되고 난 후 응답의 상태는 저장되는데 바로 다음 요청은 이 상태에 접근 할 수 있습니다. 저장된 상태는 뷰 복원 단계에서 사용 할 수 있습니다.

JSF 라이프 사이클의 개발자를 위한 요약

어느정도 JSF 개발에 익숙해진 개발자를 위해 간단하게 라이프 사이클을 코드를 이용하여 표현해 봤습니다.

• fc = FacesContext
• vh = ViewHandler
• in = UIInput
• rq = HttpServletRequest
• id = in.getClientId(fc);

1. 뷰 복원

String viewId = rq.getServletPath();
fc.setViewRoot(vh.createView(fc, viewId));

2. 요청값 적용

in.setSubmittedValue(rq.getParameter(id));

3. 검증 처리

Object value = in.getSubmittedValue();
try {
   value = in.getConvertedValue(fc, value);
   for (Validator v : in.getValidators())
      v.validate(fc, in, value);
   }
   in.setSubmittedValue(null);
   in.setValue(value);
} catch (ConverterException
   | ValidatorException e) {
   fc.addMessage(id, e.getFacesMessage());
   fc.validationFailed(); // Skips phases 4+5.
   in.setValid(false);
}

4. 모델 값 갱신

bean.setProperty(in.getValue());

5. 어플리케이션 호출(실행)

bean.submit();

6. 응답 랜더링

vh.renderView(fc, fc.getViewRoot());

출처

• http://docs.oracle.com/javaee/7/tutorial/doc/jsf-intro006.htm#BNAQQ
• https://jsf.zeef.com/bauke.scholtz#block_1484