출처 : http://www.javapattern.info
이번글은 XML을 이용한 property설정을 이용하여 jakarta-log4j의 환경설정 및
테스트 구동파일에 대한 사용방법을 설명한다.

기본적으로 log4j를 다운로드 받아야 하며, 이 패키지는 퍼포먼스최적화, 
수행중의 다른 프로그램과의 충돌등에서 여러 가지 사항을 고려한 패키지이며,
가장 간단하게 로그를 기록하고 볼수 있는 좋은 패키지이다..

우선 log4j를 다운받아 클래스패스에 추가하여 애플리케이션 형태로 도는 프로그램을
테스트해보도록 한다.

*
* @author  놀새(ienvyou@jlook.com)
* @version 1.00, 2003.02.01
* @since   log4j-1.2.7
*/

public class LogUtil {
    //private static Logger logger = LogUtil.getLogger(OtherClass.class);
public static void init(String xmlFile) {
String resource = xmlFile;
        URL configFileResource = LogUtil.class.getResource(resource);
// System.out.println("URL =======> " + configFileResource +
" ::::: " + configFileResource.getFile());
        //DOMConfigurator.configure(configFileResource.getFile());
DOMConfigurator.configure(xmlFile);
}

public static Logger getLogger(Class c) {
return Logger.getLogger(c);
}
}

다음은 해당 클래스를 테스트해볼수 있는 세개의 클래스를 나열해보도록 하겠다.

/*
* @(#)OtherClass.java 1.00 2003.02.01
*
* Copyright Choi Ji Woong,  All Rights Reserved.
*
*
*/
import org.apache.log4j.Logger;
import org.apache.log4j.xml.DOMConfigurator;

import java.io.IOException;
import java.net.URL;


/**
* XML Property logger test이네요..히히
*

*
* @author  놀새(ienvyou@jlook.com)
* @version 1.00, 2003.02.01
* @since   log4j-1.2.7
*/

public class OtherClass {
    public OtherClass() {
Logger logger = LogUtil.getLogger(OtherClass.class);
logger.debug("Other Class debug");
logger.info("Other Class info");
logger.warn("Other Class warn");
logger.fatal("Other Class fatal");
logger.error("Other Class error");
}
}

/*
* @(#)XMLPropertiesFileLoggerTest.java 1.00 2003.02.01
*
* Copyright Choi Ji Woong,  All Rights Reserved.
*
*
*/
import org.apache.log4j.Logger;
import org.apache.log4j.xml.DOMConfigurator;

import java.io.IOException;
import java.net.URL;


/**
* XML Property logger test이네요..히히
*

*
* @author  놀새(ienvyou@jlook.com)
* @version 1.00, 2003.02.01
* @since   log4j-1.2.7
*/

public class XMLPropertiesFileLoggerTest {
   

    public static void main(String argv[]) {
LogUtil.init(argv[0]);
        Logger logger = LogUtil.getLogger(XMLPropertiesFileLoggerTest.class);
        // Add a bunch of logging statements ...
        logger.debug("Hello,놀새1~");
        logger.debug("Hello,놀새2~");
        logger.debug("Hello,놀새3~");
        logger.debug("Hello,놀새4~");
        logger.debug("Hello,놀새5~");

        logger.info("놀새정보1");
        logger.info("놀새정보2");
        logger.info("놀새정보3");
        logger.info("놀새정보4");
        logger.info("놀새정보5");

        logger.warn("아뛰~ 워닝이야~1");
        logger.warn("아뛰~ 워닝이야~2");
        logger.warn("아뛰~ 워닝이야~3");
        logger.warn("아뛰~ 워닝이야~4");
        logger.warn("아뛰~ 워닝이야~5");

        logger.error("헉뚜~~ 에러야1");
        logger.error("헉뚜~~ 에러야2" , new IOException("아~ 뛰바~"));
        logger.error("헉뚜~~ 에러야3");
        logger.error("헉뚜~~ 에러야4" , new IllegalStateException("Error !!"));


        logger.fatal("엇..치명타다1");
        logger.fatal("엇..치명타다2" , new SecurityException("Fatal Exception"));
        logger.fatal("엇..치명타다3");
        logger.fatal("엇..치명타다4" , new SecurityException("Fatal Exception"));

new OtherClass();
    }
}


위와 같이 작성이 될 수 있으며 실행방법은

컴파일
javac -classpath %LOG4J_HOME%\lib\log4j-1.2.7.jar; XMLPropertiesFileLoggerTest.java


실행
java -classpath %LOG4J_HOME%\lib\log4j-1.2.7.jar; XMLPropertiesFileLoggerTest config.xml

다음페이지에서는 여러가지 환경설정을 할 수 있는 xml파일을 소개한다.


<font face='굴림'>1. console appender
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration>

<appender name="A1" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n"/>
</layout>
</appender>


<root>
<priority value ="debug" />
<appender-ref ref="A1"/>
</root>

</log4j:configuration>

2. <?xml version="1.0" encoding="euc-kr" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<!--
파일에 로그를 기록하는 샘플입니다.
기본적으로 로그파일의 이름을 기록할 수 있으며
해당설정은 root logger에 설정되어 있는 내용을 참조하여 설정이 가능합니다.
아래의 설정파일은 매일로그를 남길수 있는 형태여서 형태가 다양하게 나타날수 있습니다.
날짜변경이 되면 자동으로 로그가 바뀝니다.
-->
<log4j:configuration>

<appender name="A1" class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="ienvyou.log"/>
<param name="Append" value="false"/>
<param name="DatePattern" value="'.'yyyy-MM-dd"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n"/>
</layout>
</appender>


<root>
<priority value ="debug" />
<appender-ref ref="A1"/>
</root>

</log4j:configuration>

3.  File에 로그를 계속적으로 쌓이게 하는 방법

<?xml version="1.0" encoding="euc-kr" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<!--
파일에 로그를 기록하는 샘플입니다.
기본적으로 로그파일의 이름을 기록할 수 있으며
해당설정은 root logger에 설정되어 있는 내용을 참조하여 설정이 가능합니다.
-->
<log4j:configuration>

<appender name="A1" class="org.apache.log4j.FileAppender">
<param name="File" value="ienvyou.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n"/>
</layout>
</appender>


<root>
<priority value ="debug" />
<appender-ref ref="A1"/>
</root>

</log4j:configuration>


4. 출력을 XML포맷의 파일로 하는 방법
<?xml version="1.0" encoding="euc-kr" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<!--
파일에 로그를 기록하는 샘플입니다.
기본적으로 로그파일의 이름을 기록할 수 있으며
해당설정은 root logger에 설정되어 있는 내용을 참조하여 설정이 가능합니다.
출력은 XML형태의 파일로 저장됩니다.
-->
<log4j:configuration>

<appender name="A1" class="org.apache.log4j.FileAppender">
<param name="File" value="ienvyou.log"/>
<param name="Append" value="false"/>
<layout class="org.apache.log4j.xml.XMLLayout"/>
</appender>


<root>
<priority value ="debug" />
<appender-ref ref="A1"/>
</root>

</log4j:configuration>

5. 파일이 일정용량(예제:100KB) 이 되면 xxx.log.1, xxx.log.2의 형태로 변경시키는 방법
<?xml version="1.0" encoding="euc-kr" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<!--
파일에 로그를 기록하는 샘플입니다.
기본적으로 로그파일의 이름을 기록할 수 있으며
해당설정은 root logger에 설정되어 있는 내용을 참조하여 설정이 가능합니다.
아래의 설정파일은 일정파일사이즈가 되면 파일변경
-->
<log4j:configuration>

<appender name="A1" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="ienvyou.log"/>
<param name="Append" value="false"/>
<param name="MaxFileSize" value="100KB"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%t] %-17c{2} (%13F:%L) %3x - %m%n"/>
</layout>
</appender>


<root>
<priority value ="debug" />
<appender-ref ref="A1"/>
</root>

</log4j:configuration>

위와 같은 형태의 xml파일을 이용하면 다양한 로그를 남길수 있으며
유용하게 사용할 수 있으리라 본다.

redirect

웹컨테이너는 sendRedirect() 메소드가 호출되면 브라우저에 응답을 보내는데

이 응답에는 브라우저가 웹 컨테이너의 응답을 받은 후 다시 요청을 보낼 새로운 URL이 포함되있다.

브라우저에서 완전히 새로운 요청을 하기때문에 요청속성으로 저장되있는 객체도 리다이렉트가 발생하기전에 소멸된다.

예를들어 a.jsp에서 request에 속성값을 담아 b.jsp 로 리다이렉트 시키면... 속성값이 b페이지에

전달되지않는다.(새로운요청을 하므로...)

forward

의 경우는 포워드를 사용하여 다른자원(jsp나 servlet)으로 요청을 보내어 처리하여도

클라이언트에는 이 사실을 알리지않는다(웹 컨테이너 내에서 처리된다)

리다이렉트와 달리 새로운 요청을 위한 클라이언트와의 통신이 없어서 좀더 나은 성능을 보여준다.

그리고 포워딩시에는 포워딩후에도 요청 속성에 있는 객체들을 사용할수 있다.

그러나 포워드를 클라이언트에 알리지 않으므로(웹 컨테이너에서만 사용하니까)

URL의 변화가 없다..

____________________________________________________________________________________________________________________________

하나의 Request 를 여러 컴포넌트가 공유해야 할 경우,

(예를 들면, 하나의 Servlet 에서 Client 의 인증과 권한 부여를 처리하는 경우 등)

Request 의 공유를 구현하는 방법

1. Web Container 가 Forward 로 처리하는 방법

2. Web Container 가 Redirect 로 처리하는 방법

Redirect

브라우저가 응답을 받은 후 다시 보낼 새로운 URL 포함.

완전히 새로운 요청을 하기 때문에 Request Attribute 가 가지고 있는 객체는 Redirect 발생 시 소멸된다.

추가적으로 발생한 왕복 처리 때문에 Forward 보다 느리다.

URL 에 파라미터가 보이므로, 중요한 정보는 포함하지 않도록 유의해야 한다.

                                               (1) HTTP 요청

           Browser (Client)            ---------------->                Web Container (Server)

        ====================                                               =========================

                                                                                         (2) 요청 처리

                                                (3) 응답 Return

                                              <----------------

                                                (4) 새로운 요청

                                               ----------------->

                                                 (5) HTTP 응답

                                               <----------------

사용 예 : response.sendRedirect (request.encodeRedirectURL ("http://xxxxxx/result.jsp?...")

Forward

Forward 되는 해당 요청이 다른 Servlet 에 전달된다.

이 때, Client 는 다른 Servlet 에서 이 요청을 처리할 것을 모른다.

Client 와 통신 없이 서버에서만 처리되기 때문에, Redirect 보다 더 나은 성능 보인다.

Forward 한 후에도 객체를 사용할 수 있으므로, 객체가 가지고 있던 Request Attribute 를 사용할 수 있다.

URL 에는 변화가 없으므로 URL 과 Client Application 이 일치하지 않을 수 있다.

이는 Forward 가 발생한 사실을 Client 가 알지 못하기 때문이다. Refresh 를 할 경우, 정확하지 않은 요청이 발생할 수 있다.

Struts Framework 는 기본으로 Forward 를 사용한다.

                                               (1) HTTP 요청

           Browser (Client)            ---------------->                Web Container (Server)

        ====================                                               =========================

                                                                                         (2) 요청 처리

                                                                                         (3) Forward 수행

                                                (4) HTTP 응답

                                               <----------------

사용 예 : RequestDispatcher dispatcher =

                                         request.getRequestDispatcher("/result.jsp?....");

             dispatcher.forward(request, response);

(RequestDispatcher.forward() 는 Client 에 어떠한 결과도 전달하지 않았을 경우 사용 가능하다.)

오늘은 forward와 include의 비교 입니다
forward와 include 모두 서블릿에서 흐름을 제어할때 쓰이는 메소드 입니다.
forward는 A에서 forward(B)를 한다면 forward를 호출하기전까지 전부 해석하다가 호출하는 시점에 B로 흐름이 넘어갑니다.
즉 아직까지 request는 한번 입니다
include는 A에서 include(B)를 한다면 A에서 include 호출하기전까지 모두 해석
-> B로 흐름 넘어가서 B 전부 해석하고 끝나면 -> 다시 A의 호출문장으로 넘어옵니다.
여기서도 request는 한번입니다.
근데 sendRedirect 라는 놈이 있는데요 이놈은 request가 두번이 일어납니다.
왜냐면  sendRedirect는 특정주소를 호출할 것을 요청하는 응답신호를 브라우저에게 보내기 때문입니다. 즉 A에서 sendeRedirect(B)를 한다면 A -> B -> A -> B
그래서 request 가 두번 발생하는것입니다.

Strat.html

<html>
   <head>
  <title> forward 및 include , sendRedirect 때려잡기! </title>
  </head>
  <body>
  <form action="Check.jsp" method="post">
    당신의 나이는?
   <input type="text" name="test"><br><br>

    <input type="radio" name="check" value="forward"> forward 방식
    <input type="radio" name="check" value="include">  include 방식
    <input type="submit" value="Confirm">
 </form>
 </body>
</html>

간단히 forward와 include중 어느 형식으로 보낼것인치 체크하고 나이를 넣게 했습니다.

Check.jsp

<%
String check = request.getParameter("check");
java.util.Date today = java.util.Calendar.getInstance().getTime();
%>

 이건 include 할때만 보여요~ ^^ 
<hr>
<% if (check.equals("forward"))
{%>
  <jsp:forward page="./Result.jsp" >
  <jsp:param name="check" value="<%=check%>"/>
  <jsp:param name="today" value="<%=today%>"/>
  </jsp:forward>
   <hr>
<%  } else  if  (check.equals("include")) { %>
<jsp:include page="./Result.jsp">
  <jsp:param name="check" value="<%=check%>"/>
  <jsp:param name="today" value="<%=today%>"/>
</jsp:include>
<%  }  %>

이것은 결과 페이지(result.jsp)에 가기전에 forward와 include의 차이점을 보여주는 페이지

일단 포워드는 호출하면 그 위까지만 해석하고 바로 흐름이 바뀌기 때문에 " 이건 include 할때만 보여요~ ^^"라는 문장은 해석은 하지만 뿌리지는 못합니다.

그래서 그럼 이넘이 과연 해석은 정말 하고 가는가 의문이 들어서 시간을 넘는 today를 만들어서 넘겼습니다.

Result.jsp

<br>
 이것은 <%= request.getParameter("check")  %>  방식입니다.
<hr>
나이 : <%=request.getParameter("test")%>
<hr>
현재 시간 : <%= request.getParameter("today")%>

 이건 결과 페이지입니다.

                                                    forward의 실행화면

특정 쓰레드의 스코프에서 사용할 로컬변수가 필요했던 적이 있는가? 이때에 각각의 쓰레드는 고유의 스토리지를 갖고 하나의 쓰레드는 다른 쓰레드의 상태 정보를 액세스하는 것이 불가능할 것이다. 표준 라이브러리는 이러한 요구를 가능케 하는 ThreadLocal 과 InheritableThreadLocal, 2개의 클래스들을 제공하고 있다.

클래스들이 사용되고 있는 예를 보자.

  import java.util.Random;

  public class ThreadLocal1 {

    // Define/create thread local variable
    static ThreadLocal threadLocal = 
                                   new ThreadLocal();
    // Create class variable
    static volatile int counter = 0;
    // For random number generation
    static Random random = new Random();

    // Displays thread local variable, counter, 
    // and thread name
    private static void displayValues() {
      System.out.println (
        threadLocal.get() + "\t" + counter +
        "\t" + Thread.currentThread().getName());
    }

    public static void main (String args[]) {

      // Each thread increments counter
      // Displays variable info
      // And sleeps for the random amount of time
      // Before displaying info again
      Runnable runner = new Runnable() {
        public void run() {
          synchronized(ThreadLocal1.class) {
            counter++;
          }
          threadLocal.set(
             new Integer(random.nextInt(1000)));
          displayValues();
          try {
            Thread.currentThread().sleep (
              ((Integer)threadLocal.get()).intValue());
            displayValues();
          } catch (InterruptedException e) {
            e.printStackTrace();
          }
        }
      };

      // Increment counter, access thread local from 
      // a different thread, and display the values
      synchronized(ThreadLocal1.class) {
          counter++;
      }
      threadLocal.set(
         new Integer(random.nextInt(1000)));
      displayValues();

      // Here's where the other threads
      //  are actually created
      for (int i=0; i<5; i++) {
        Thread t = new Thread(runner);
        t.start();
      }
    }
  }

ThreadLocal1클래스는 2개의 정적 변수를 갖는다. common integer primitive 타입인 counter와 ThreadLocal 타입의 변수인 threadLocal이 바로 그것이다. 일반적으로 클래스 변수를 사용하면, 해당 클래스의 모든 인스턴스들은 동일한 값을 공유하게 된다. 하지만 ThreadLocal의 경우는 다르다. ThreadLocal클래스를 사용하면 동일한 쓰레드내에서만 같은 정적 정보를 공유하게 되는 반면, 서로 다른 쓰레드에서 ThreadLocal 클래스를 사용하면 서로 다른 정적 정보를 갖게 된다.

ThreadLocal1에서, ThreadLocal 인스턴스는 0에서 999사이의 랜덤한 숫자로 초기화된다.

   threadLocal.set(
     new Integer(random.nextInt(1000)));

다수의 서로 다른 쓰레드가 생성되었다. 각각의 쓰레드 별로, 2개의 클래스 변수에 대한 상태 정보가 디스플레이된다. 그러면 이 쓰레드는 ThreadLocal이 랜덤한 숫자로 지정한 만큼의 밀리초동안 휴면한다. 이후, 2개의 클래스 변수의 상태 정보가 다시 디스플레이되고, ThreadLocal1를 실행하면, 아래와 같은 출력값을 보게 된다.

   828     1       main
   371     2       Thread-0
   744     3       Thread-1
   734     4       Thread-2
   189     5       Thread-3
   790     6       Thread-4
   189     6       Thread-3
   371     6       Thread-0
   734     6       Thread-2
   744     6       Thread-1
   790     6       Thread-4

여기에서 주목할 것은 세번째 컬럼에서 쓰레드의 이름이 같을 때를 살펴보면, 첫번째 컬럼의 ThreadLocal 변수값이 프로그램이 실행되는 동안 같은 상태를 유지한다는 것이다. 반면, 두번째 컬럼에서 보이는 정적 변수는 프로그램이 실행하는 동안 변화하고, 기존 쓰레드를 재검토할 때 그 바뀐 값을 유지한다. 이것이 바로 적절하게 동기화된 정적 변수가 해야 하는 일이다.

프로그램을 실행할 때마다 모든 컬럼에는 각기 다른 값이 생성되기 때문에 결과에서 보이는 첫번째 컬럼의 시간들이 위에서 보는 바와 다르다거나, 마지막 5개의 행의 이름의 순서가 다르다고 해도 놀랄 필요는 없다. 그 순서는 첫번째 컬럼에서 보여진 시간(times)에 기반한 것이다.

쓰레드 로컬 변수는 단순히 인스턴스 변수들의 또 다른 형태만이 아니다. 만약 특정 클래스의 10개의 인스턴스를 모두 일반적인 쓰래드내에서 접근한다면, 그것들의 ThreadLocal 정보는 모두 같을 것이다. 그러나, 만약 이러한 인스턴스들 중의 하나를 다른 쓰레드에서 접근하게 되면, ThreadLocal 정보는 바뀌게 될 것이다.

ThreadLocal 클래스는 오직 3개의 메소드만을 포함하고 있는데 get, set과 initialValue가 바로 그것이다. ThreadLocal1 예제를 보면, set메소드는 인스턴스가 생성된 이후 호출되는 것을 알 수 있다. ThreadLocal의 상태를 이후에 다시 초기화하는 방법 대신에, ThreadLocal을 상속한 서브클래스에서 initialValue 메소드를 오버라이드할 수 있다. 다음의 ThreadLocal2 클래스가 바로 그 일을 하는데, 생성된 출력값은 ThreadLocal1의 경우와 비슷하다.

   import java.util.Random;

   public class ThreadLocal2 {

     // Create thread local class
     // Initial value is a random number from 0-999
     private static class MyThreadLocal
                                  extends ThreadLocal {
       Random random = new Random();
       protected Object initialValue() {
         return new Integer(random.nextInt(1000));
       }
     }

     // Define/create thread local variable
     static ThreadLocal threadLocal =
                           new MyThreadLocal();

     // Create class variable
     static volatile int counter = 0;

     // For random number generation
     static Random random = new Random();

     // Displays thread local variable, counter,
     // and thread name
     private static void displayValues() {
       System.out.println (
         threadLocal.get() + "\t" + counter +
         "\t" + Thread.currentThread().getName());
     }
    
     public static void main (String args[]) {

       // Each thread increments counter
       // Displays variable info
       // And sleeps for the random amount of time
       // Before displaying info again
       Runnable runner = new Runnable() {
         public void run() {
           synchronized(ThreadLocal2.class) {
             counter++;
           }
           displayValues();
           try {
             Thread.currentThread().sleep (
               ((Integer)threadLocal.get()).intValue());
             displayValues();
           } catch (InterruptedException e) {
             e.printStackTrace();
           }
         }
       };

       // Another instance of class created
       // and values displayed
       displayValues();

       // Here's where the other threads
       // are actually created
       for (int i=0; i<5; i++) {
         Thread t = new Thread(runner);
         t.start();
       }
     }
   } 

ThreadLocal의 initialValue 메소드는 각각의 쓰레드가 상태를 알아내기 위해 하는 첫번째 호출에서 사용된다. Set이 이미 호출된 상태라면, initialValue 메소드는 절대로 호출되지 않는다. initialValue 메소드를 사용할 때, public이 아니라 protected로 만들어야 한다는 것을 기억하자. 일반적으로 initialValue 메소드가 임의로 호출되는 것은 바람직하지 않기 때문이다. initialValue 가 오버라이드되지 않았을 경우, 쓰레드 로컬 변수를 나타내는 객체의 초기 값은 null이다.

ThreadLocal변수에 담을 컨텐츠는 어떤 Object 타입이든지 가능하다. ThreadLocal2에서 컨텐츠는 Integer이다. get을 이용해서 상태를 받아낼 때 Object를 적절한 타입으로 캐스팅해야 한다는 것을 기억하자.

InheritableThreadLocal라고 불리는 ThreadLocal의 두번째 타입을 보자. ThreadLocal과 같이, InheritableThreadLocal을 사용하는 각각의 쓰레드는 고유의 상태객체를 갖는다. ThreadLocal과 InheritableThreadLocal의 차이점은 InheritableThreadLocal의 초기값은 생성하는 쓰레드로부터 변수의 상태를 얻어낸다는 데에 있다. 상태의 변경은 다른 쓰레드를 제외한 로컬 쓰레드에서만 가능하다. InheritableThreadLocal의 새로운 childValue 메소드는 그것의 상태를 초기화하기위해 사용되는데 이는 상태를 얻어내려고 할 때가 아니라 자녀객체의 생성자에 의해 호출된다.

실제로 ThreadLocal의 사용을 검토하기 위해서는, java.nio.charset의 Charset 클래스를 보거나 java.util.Logging의 LogRecord를 참고한다. Charset의 경우에는, ThreadLocal가 캐릭터 세트 인코더와 디코더를 검색하기 위해 사용된다. 이것은 초기화하는 코드들이 절절한 시기에 사용되도록 조절하는 역할을 한다. LogRecord에서 ThreadLocal의 사용은 각각의 쓰레드에 Login을 위한 고유한 id가 할당되는 것을 보장해 준다.

Custom Tag Library (9) - 중첩 연관 태그 구현
중첩 연관 태그 구현

한글로 쓰다 보니 정말 말이 어렵게 보인다. 중첩 연관 태그… 그냥 이 문장만 봐서 "아하~ 그걸 말하는 구나"라고 생각하는 분이 계신다면 천재임에 틀림없다. 앞에서 조금 언급했기에 망정이지 안그랬으면 아마도 필자는 여러분들의 질타와 야유를 감수해야 했을 것이다.
이 부분에서 우리가 먼저 알아두어야 할 것은 두가지이다. 그 첫째는 현재 버전의 API에서는 자신의 부모 태그를 찾을 수 있는 메커니즘은 있지만, 자식 태그를 찾을 수 있는 방법은 없다.
부모 태그를 찾는 메쏘드가 바로 findAncestorWithClass라는 메쏘드이다. 이 메쏘드는 자기 자신과 찾으려는 부모 태그를 아규먼트로 넘겨 받아서 찾게 된다. API를 보면 다음과 같이 나와 있다.

final 메쏘드이기 때문에 오버라이드 할 수 없으며, 아규먼트는 위에서 언급한 대로이다.
두번째 아규먼트는 Class 클래스이므로 부모 태그의 클래스의 Class 클래스를 넣어야 한다.

말이 어째 좀 이상한데 부모 태그.class와 같은 형식이다라고 생각하면 된다. 만약 부모 태그를 찾지 못하면 JspTagException 예외를 발생시킨다. 두번째로 알아야 할 것은 자식 태그는 부모 태그와 연관을 맺고 있기 때문에 부모 태그가 가지는 특정 값을 받아올 수가 있어야 한다. 따라서, 부모 태그는 자식 태그가 어떤 값에 접근할 수 있는 메쏘드를 제공해야 한다. 우리의 목표는 조 건처리를 위한 중첩 태그를 구현하는 것이다. 이러한 태그의 구조는 아래와 같을 것이다.

<prefix:if>
  <prefix:condition>true | false</prefix:condition>
  <prefix:then> if condition is true then process something </prefix:then>
  <prefix:else> if condition is false then process something </prefix:else>
</prefix:if>

이 태그는 프로그래밍의 전형적인 조건문인 아래와 같은 형태와 일치하는 것이다.

차례대로 태그 핸들러를 구현해 보도록 하자.

소스 5.23 IfTag.java

package com.boolpae.jsp;

변수는 condition 과 hasCondition, 두가지이며 이 두가지 변수를 설정하고 접근하기 위한 메쏘드들이 나열되어 있다. condition은 진리 값의 true|false를 설정하는 것이며 hasCondition은 문법적인 검사를 위한 것이다. 만약 condition이 if 태그 내부에 없다면 항상 hasCondition은 false가 될 것이다.(초기값이 false이니까) 계속해서 나올 condition 태그에서 setHasCondition 메쏘드를 사용해 hasCondition 값을 true로 설정하게 된다.

소스 5.24 IfConditionTag.java

package com.boolpae.jsp;

IfConditionTag 클래스는 먼저 doStartTag에서 findAncestorWithClass 메쏘드를 사용해서 부모 태그(IfTag)를 찾는다. 부모 태그가 없다면 예외를 던지고 실행을 중단한다. 부모 태그를 찾게되면 계속 몸체 수행을 하게 된다. 몸체의 값이 true이면 IfTag 클래스의 condtion값을 true로 설정하게 되고 아니면 false로 설정하게 된다. 여기서는 그냥 equals 메쏘드를 사용했기 때문에 대소문자를 구별한다. 대소문자 구별할 필요가 없다면 equalsIgnoreCase 메쏘드를 사용하라. 그러고 나면 이 태그에 대한 처리가 모두 끝나고 SKIP_BODY를 리턴하게 된다. 다음으로 IfThenTag 태그 핸들러 클래스를 보자.

소스 5.25 IfThenTag.java

package com.boolpae.jsp;

IfThen 태그 역시 doStartTag 메쏘드에서 부모 태그를 찾는다. 부모 태그(IfTag)가 없다면 역시 예외를 던진다. 또한 hasCondition이 false일 때도 예외를 던진다. 왜냐면 IfCondition 태그를 거치지 않았다는 의미이기 때문이다. Condition없는 조건문은 생각할 수 없다. hasCondition이 true라면 문법에 맞으므로 EVAL_BODY_TAG를 리턴하고 doAfterBody 메쏘드를 수행하게 된다. doAfterBody 메쏘드는 IfTag 의 condition이 true인지를 검사하고 true가 아니라면 예외를 던져버린다. IfThen 은 condition이 true일 때만 수행되는 태그이기 때문이다. true라면 몸체를 출력하는 일을 하게 된다.

소스 5.26 IfElseTag.java

package com.boolpae.jsp;

IfElseTag 클래스도 IfThen 클래스와 다를 바 없다. doStartTag는 IfThen 클래스와 동일하게 문법상 적합한지 검사하고 문법상 문제가 없다면 doAfterBody 메쏘드를 수행시킨다. 그러면 condition의 값을 검사하고 false일 때만 몸체를 출력하게 된다.
이것으로 태그핸들러 클래스 작성은 끝났다. 이제 우리가 만들었던 4개의 태그 핸들러를 우리가 지금까지 쭈욱~ 해왔던 대로 TLD 파일에 추가하면 된다.

소스 5.27은 taglibExample.tld 에 추가하여야 할 부분이다.

소스 5.27 taglibExample.tld 추가

<tag>
	<name>if</name>
	<tagclass>com.boolpae.jsp.IfTag</tagclass>
	<info>If Tag</info>
	<bodycontent>JSP</bodycontent>
</tag>

<tag>
   <name>condition</name>
   <tagclass>com.boolpae.jsp.IfConditionTag</tagclass>
   <info>IfCondition Tag</info>
   <bodycontent>JSP</bodycontent>
</tag>

<tag>
   <name>then</name>
   <tagclass>com.boolpae.jsp.IfThenTag</tagclass>
   <info>IfThen Tag</info>
   <bodycontent>JSP</bodycontent>
</tag>

<tag>
   <name>else</name>
   <tagclass>com.boolpae.jsp.IfElseTag</tagclass>
   <info>IfElse Tag</info>
   <bodycontent>JSP</bodycontent>
</tag>

TLD 파일에 대해서는 특별히 설명할 것이 없다. 여러분도 이미 익숙해 졌으리라 생각된다. 이제 JSP 페이지를 만들어서 실행해 보자. 우리가 만들어볼 JSP 페이지에는 이 태그를 두번 사용한다.

하나는 condition은 파라미터로 받고 condition의 상태를 출력하고, 다른 하나는 우리가 예전에 만들었던 loop 태그를 사용하여 랜덤하게 Math.random() 메쏘드를 사용하여 0.5 보다 크면 크다는 문장을, 작으면 작다는 문장을 출력할 것이다.

소스 5.28 IfTagExample.jsp

<HTML>
<HEAD>
<TITLE> 중첩 연관 태그 예제 </TITLE>
<style> BODY {font-size:15pt } </style>
</HEAD>
<BODY>
<center>
<h1> 중첩 연관 태그 Example </h1>
<%@ taglib uri="WEB-INF/tlds/taglibExample.tld" prefix="jspace" %>

<jspace:if>
<jspace:condition><%=request.getParameter("condition")%></jspace:condition>
<jspace:then>Condition is true</jspace:then>
<jspace:else>Condition is false</jspace:else>
</jspace:if>
<hr>
<jspace:loop repeats='10'>
<jspace:if>
<jspace:condition><%=Math.random() > 0.5%></jspace:condition>
<jspace:then>The number is greater than 0.5<br></jspace:then>
<jspace:else>The number is smaller than 0.5<br></jspace:else>
</jspace:if>
</jspace:loop>
</BODY>
</HTML>

실행결과 화면은 아래와 같다.

이번 chapter도 이것으로 끝이 났다. JSP만의 기술적인 부분은 대부분 정리가 끝났다. 과연 우리는 지금까지 배운 것들을 가지고 얼마나 효율적으로 사용하여 틈만 나면 떠들어댔던 프리젠테이션과 비즈니스 로직의 분리라는…, 컴포넌트의 재사용이라는… , 지금까지 다른 스크립트 언어들이 할 수 없었던 일들을 할 수 있는 것일까?

여러분의 느낌은 어떤한지 모르겠다. "솔직히 말해서 배우기가 힘들다." "뭐 때문에 이렇게 하는 것일까?" 이런 대답을 한다면 필자가 강좌를 잘못 썼기 때문이다라고 자책할 수 밖에 없겠다. 사실 설계 단계부터 조금은 힘들고 구현에도 더 많은 양의 코드가 들어갈 것이다. 처음 개발할 때 일반적인 ASP나 PHP 등으로 코딩하는 것보다 시간도 많이 걸릴 것이다. 물론 JSP로도 그렇게 코딩하면 마찬가지이다. 어떤 식으로 할지는 프로젝트의 상황에 따라 달라질 것이다. 또한 코드가 조금 엉망이더라도 하드웨어가 좋으면 그런 오버헤드는 무마될 수 있다. 코드를 최적화하는데 들어가는 인력비보다 하드웨어에 투자하는 것이 비용절감 측면에서 더 나을지도 모른다. 하지만, 그 어플리케이션을 언젠가는 수정해야 한다면 뜯어 고치는데 들어가는 비용은 참으로 많을 것이다. 조금 힘들더라도 훗날을 생각해서 JSP의 철학이 담긴 코딩을 하도록 노력하자. 하드웨어가 아무리 좋아져도 언젠가는 소프트웨어를 뜯어 고쳐야 할 날이 올 테니까… 그럴 수 없는 상황이라면 페이지 중심으로 설계한다고 해도 조금은 신경을 써서 미래를 생각하는 버릇을 기르자.

요즘 JSP로 웹어플리케이션을 설계하는데 있어서 MVC 아키텍쳐 이야기를 여기저기서 말하고 있는데, 필자는 MVC 아키텍처 모델이 무엇인지 잘 모른다. 디자인 패턴에서 나온 이야기인 것 같은데 그 깊숙한 부분에 대해서도 잘 모르기 때문에 우리의 프로그램이 MVC 아키텍처를 따라 모델링 되어야 하고 구현되어야 한다고 말하지 않겠다.(MVC 모델은 SmallTalk에서 처음 도입되었다고 한다. 주로 GUI 어플리케이션에 많이 적용되는 디자인 패턴이다.)

그저 필자가 강조했던 JSP의 철학을 구현하려고 노력하다 보면 이미 그 프로그램은 MVC 모델의 관점에서도 잘 정의된 프로그램이 되어 있을 것이라고 말하고 싶다. 디자인 패턴에 대해서 관심이 있는 독자들에게는 책으로 Thinking in Patterns with Java(Bruce Eckel 저)을 추천한다. 아쉽게도 번역판은 없다. J2EE 플랫폼에서의 MVC 모델에 관련해서는 Sun의 웹사이트
http://java.sun.com/j2ee/blueprints/design_patterns/mvc/index.html을 참고하면 되겠다. EJB 중심으로 설명되어 있지만 개념적인 부분은 비슷하다.

이랬거나 저랬거나 우리는 앞으로 2개의 chapter를 더 할애해서 이론적인 부분을 더 살펴봐야 할 것 같다. 하나는 세션과 쿠키에 관련된 이야기이며 다른 하나는 데이터베이스와의 연동을 위한 JDBC가 될 것이다.