세상을 개발하는 남자

 스프링 프레임워크는 IoC를 사용해 컴포넌트들을 관리한다. 컴포넌트간의 연관관계 등을 관리함으로써 객체를 명확하게 이해하고, 재사용이 가능하며, 단위테스트가 쉬워진다. 스프링은 이러한 컨테이너를 두가지 포함하고 있는데, 빈 팩토리와 애플리케이션 컨텍스트가 그것이다.

빈 팩토리는 기본적인 의존성 주입을 지원하는 가장 간단한 형태의 컨테이너이다.
애플리케이션 컨텍스트는 빈 팩토리의 개념 위에 프로퍼티 파일을 해석하고 이벤트를 발행하는 등의 능력이 구현된 것으로, 대부분의 경우 애플리케이션 컨텍스트를 많이 사용한다.

빈 팩토리는 org.springframework.beans.factory.BeanFactory 인터페이스로 정의 되고, 스프링 안에 많은 구현 클래스들이 존재한다. 그중 org.springframework.beans.factory.xml.XmlBeanFactory 가 가장 유용하다. 사용법은 아래와 같다.

BeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml"));

이 코드는 빈에 대한 정의만 읽어올 뿐 인스턴스화 하지는 않는다. 빈 자체가 필요하게 되기 전까지 인스턴스화 하지 않는데, 이를 "늦게 로딩(lazy loading)"된다고 말한다.

빈을 얻어오기 위해서는 다음과 같이 코드를 작성한다.

MyBean myBean = (MyBean) factory.getBean("myBean");

getBean()에 의해 팩토리는 의존성 주입을 통해 빈을 인스턴스화 한다.

애플리케이션 컨텍스트는 org.springframework.context.ApplicationContext 인터페이스로 정의되고, 구현 클래스들 중 일반적으로 사용되는 세 개는 다음과 같다.

ClassPathXmlApplicatoinContext : 클래스 경로에 있는 xml파일로부터 로딩
  예) ApplicationContext context = new ClassPathXmlApplicatoinContext("c:/config.xml");

FileSystemXmlApplicationContext : 파일 시스템에 있는 xml파일로부터 로딩
  예) ApplicationContext context = new FileSystemXmlApplicationContext("config.xml");

XmlWebApplicationContext : 웹 애플리케이션에 포함되있는데 xml파일로부터 로딩


 애플리케이션 컨텍스트는 싱글톤 방식으로 빈을 관리한다. 즉 컨텍스트를 시작시킬 때 모든 빈 들을 미리 로딩한다. 싱글톤 빈을 미리 로딩함으로써, 그 빈이 필요할 때 즉시 사용될 수 있도록 해준다.

이 글은 스프링노트에서 작성되었습니다.

 관점지향 프로그래밍.

정말 지친다, 지쳐.

왜 이렇게 용어를 어렵게 만들어놨는지..;

각설하고

관점지향 프로그래밍 역시 별거 아니였다(라고 말할 수 있는 입장은 아니지만;)

나같은 초보 분들께 드리고 싶은 말은.. 용어의 압박감으로부터 벗어나라!(머 이런 뜻이였음.)

관점을 지향한다... 여기서 관점은.. 스프링에서의 관점은 글쎄... 시점이라는 표현이 더 적절치 않나 싶다.

어떤 '시점'에서 Aspect들이 실행되야 하는지가 중요한 관건인것 같아서이다.

(관점이라는 말은 보편적으로 '사물을 보는 시각' 따위로 쓰이는데 관점지향.. 이해만 어려워진것 같다.)

에스펙트는 '스프링인액션'의 번역본에 따르면 횡단 관심사의 기능이라고 되어있다...

(정말... 용어들이 갈수록 과관이다..횡단;; 관심사라;;;)

요점 부터 말하자면;;; AOP는 개발자가 비즈니스 로직에만 집중할 수 있도록

기타 시스템에 관한 서비스(로깅이나 트랜잭션 관리)들을 분리해 놓는 것이다.

즉, 여러 영역에서 '중복'될 수 있는 시스템 관련 코드들을 한곳에서 관리하여 중복도 줄이고

더이상 로직구현이 아닌 부분에 대해서는 개발자가 신경을 쓰지 않도록 하는 것이 취지이다.

(정말 필요하다. 웹 플밍으로 전향하고서 느낀 점인데.. 이 쪽은,

실제 프로그래밍 보다 '기타등등(계층간 설정, 버전 궁합 등)'들에 더 많이 신경써야하는 것 같다..)

다시 쉽게 말해서 로깅 같은 것들을 따로 로그 클래스로 만들어서,

메소드의 시작 전에 호출을 할지 메소드 후에 실행시킬지,

아니면 두번 다 실행시킬지 등등을 xml 설정으로 쉽게 관리 할 수 있게 해주는 것이다.. IoC 개념으로 말이다.

(그래서 시점지향이라고 하는게 맞지 않나..싶다. 왜 관점이어야 하는지 아시는 분은 답글 부탁드림.)

(다음은 AOP관련 용어 설명)

여기에서  로깅(로그를 하는 행위, 기능)이 aspect이고 로그 클래스(실제 구현물)가 advice(충고)이다.

그리고 '애스펙트'를 집어넣을 수 있는 지점들, 즉 메소드, 예외 등이 joinpoint(결합점)가 되고,

실제로 '결합점' 중에서 한 곳에 '충고'를 적용시키면, 그곳이 pointcut(교차점)이 된다.

target(대상)이란 '충고'를 받는 클래스, 즉 pointcut을 포함하는 클래스를 '충고'의 target이라고 말하고

proxy(프록시)는 '대상' 객체에 '충고'가 적용된 후 생성되는 객체를 말한다.

또한 기존의 클래스에 새로운 메소드나 속성을 추가할 수 도 있는데 이는 introduction(도입)이라 부른다.

weaving(엮기)는 애스펙트를 타겟에 적용하여 새로운 프록시 객체를 생성하는 과정이다.

이 '엮기'는 런타임시 어떤 시점에 '엮이게' 하는 것이 일반적이고,

컴파일시, 클래스 로딩시에 '엮을' 수도 있는데 이런 경우 각각 특수 컴파일러와 특수 ClassLoader가 필요하다.

 (헥헥..)

그렇다면 cross-cutting concern(횡단 관심사)란 무엇이냐.. 다음 그림이 크로스 커팅 컨썬이다.-_-

(여기서 또 횡단 관심사의 '관심사'가 왜 '관심사'여야 하는지 모르겠다. 그냥  횡단 기능 등이라고 했으면 이해가 더 쉬웠을텐데..

초짜들에게 혼란만 가중시키는 잘못된 역이 아닌가 싶다. 너무 직역을 해야한다는 압박감을 가진 모양이다. 역자님께서..

혹시 '관심사' 여야 하는 이유를 아시는 분은-_- 댓글부탁.)

코스와 학생, Misc(??) 의 각각의 영역에서 모듈들이 서비스를 제공할때,

이 모듈들은 보안기능 또는 트랜잭션등을 포함하고 있다 치면,

이런 것들은 공통적으로 사용되는 기능들일 것이다.

이론 공통적인 부분을 재사용하기 위해 일반적인 객체 지향 기법으로는 상속이나 위임으로 해결할 수 있는데,

상속을 하게 되면, 객체의 계층도가 무너지고,

(생각해보라. 다이어그램을 그리는데 전혀 관계없는 객체들이 곳곳에서 한 클래스를 상속하면..;)

 위임을 사용하면 번거로워 지며, 위임한 객체에 대한 중복 호출을 필요로 한다.

그래서 AOP를 사용하는 것이다.

AOP를 적용하면 공통 기능을 한 곳에서 정의할 수 있고 그런 기능을 어디에 어떻게 적용할 것인지를 선언적으로 정의할 수 있다.

이 글은 스프링노트에서 작성되었습니다.

struts-config.xml에서의 설정으로는 동적으로 바뀌는 파라메터를 넘겨줄 수 없다.

그래서, 액션 클래스에서의 특별한 처리를 요구하는 데, 다음중 한 방법을 사용하면 된다.

1.  ActionFoward 객체 직접 생성

   다음과 같이 ActionForward객체를 생성하여 리턴한다.
   return new ActionForward("/index.html?param=" + paramValue, true);

   파라메터가 많을 경우 코드가 지저분해지고 번거러울 수 있다.

   
   

2. ActionMapping객체를 통한 ActionFoward객체 생성

   대부분의 경우 이같은 방법으로 포워드시킨다.

   excute() 메소드에서 전달 받은 ActionMapping 객체를 이용한다.
   ActionForward forward = mapping.findForward("success");
   ActionForward redirect

   = new ActionForward(forward.getName(), forward.getPath()
   + "?param=" + paramValue, true );

   return redirect;

   
   

3. ActionRedirect 클래스 활용

   org.apache.struts.action.ActionRedirect 클래스를 import시켜서 사용한다.
   ActionRedirect redirect = new ActionRedirect( mapping.findForward("success") );
     redirect.addParameter("param", paramValue);
   return redirect;
   * 주의 : 이 방법은 struts 1.2.7 버전 부터 가능하다.

이 글은 스프링노트에서 작성되었습니다.

 IoC(Inversion of Controll)는 우리말로 제어의 역행 쯤 되시겠다. 그렇다면 제어가 역행됬다는 것은 무슨 뜻인가?

지금까지 객체를 생성하고 각 객체 간의 의존관계(생성하고 머 그런거)를 제어하는 권한은 우리 개발자들에게 있었다. 하지만 서블릿, EJB가 등장하면서 제어권이 서블릿과 ejb를 관리하는 컨테이너에게로 넘어가 버렸다. 개발자들이 서블릿과 ejb를 직접 생성하고 싶어도 이 객체들은 직접 생성하여 제어할 수 없고 객체 생성에 대한 제어권이 컨테이너에게 넘어가면서 객체의 생명주기를 관리하는 권한또한 컨테이너들이 전담할 수 밖에 없게 되었다. 제어권 역전 현상이란 바로 이것을 의미하며, 스프링도 컨테이너처럼 이런 현상(?)을 이용하고 있다. 즉, 스프링 역시 내부에 IoC개념, 객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 제공하고 있다.

스프링은 POJO(Plain Old Java Object : 개발자에 의해 생성/관리되는 평범한 객체 되시겠다.)를 관리하는 컨테이너 역할을 가지고 있다. 즉, 개발자에 의해 정의된 객체(POJO)들을 xml설정에 따라 애플리케이션 시작과 동시에 생성하고 관리하여 주기때문에(기본적으로 그러하다) 컨테이너의 기능상 장점과 POJO 만의 장점을 함께 누릴 수 있는 것이다.
이것이 스프링의 IoC, 역행제어이다.

다음 편에 계속..-_-

'역행 제어'
이 압박감 심한 단어 때문에 어려운 내용일꺼야 지레 겁부터 먹었는데
알고보면 역행제어란 그리 어려운 개념이 아니었습니다.
공부하면서 항상 느끼는 거지만
용어들... 너무 압박감이 심하네요ㅠ

이 글은 스프링노트에서 작성되었습니다.

스트럿츠에서 자공하는 파일업로드 유틸을 사용할 경우
데이터 베이스에 한글 파일명은 깨져서 기입되는데,
결국은 방법을 찾아내었다.
다음과 같이 필터를 사용하면 된다.


package study.filter;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class EncodingFilter implements Filter {
   
    private String encoding = null;
    protected FilterConfig filterConfig = null;
   
    public void destroy() {
        this.encoding = null;
        this.filterConfig = null;
    }
   
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    throws IOException, ServletException {
        if(request.getCharacterEncoding() == null) {
            if(encoding != null) {
                request.setCharacterEncoding(encoding);
            }           
        }
       chain.doFilter(request, response);
    }   
   
    public void init(FilterConfig filterConfig) throws ServletException {
         this.filterConfig = filterConfig;
         this.encoding = filterConfig.getInitParameter("encoding");
    }
   
    public FilterConfig getFilterConfig() {
        return filterConfig;
    }
   
    public void setFilterConfig(FilterConfig cfg) {
        filterConfig = cfg;
    }  
}


위와같이 클래스를 생성하고
web.xml에서 필터를 등록한다.


    <web-app>


        <filter>
            <filter-name>Encoding Filter</filter-name>           
            <filter-class>study.filter.EncodingFilter</filter-class>
            <init-param>
                <param-name>encoding</param-name>
                <param-value>EUC-KR</param-value>           
            </init-param>
        </filter>

        <filter-mapping>
            <filter-name>Encoding Filter</filter-name>
            <url-pattern>/*</url-pattern>
        </filter-mapping>


    </web-app>

Struts 프레임웍은 일반적으로 에플리케이션에서 필요한 각 입력폼당 하나의 ActionForm빈(이는 ActionForm을 상속하는 Java클래스임.) 하나를 정의한다고 가정합니다. ActionForm빈들은 때때로 "form beans"라고 불립니다. 만일 ActionMapping 설정 파일(Contoller 컴포넌트 만들기 참고)에 이같은 빈들을 선언하면, Struts 컨트롤러 서블릿은 적절한 Action메소드를 호출하기 전에 자동적으로 다음의 서비스들을 수행합니다.

• 적절한 키, 적절한 클래스의 빈 인스턴스가 사용자의 session에 있는지 체크합니다.
• 만일 이 같은 session scope 빈 인스턴스가 없다면, 자동으로 생성하고 이를 사용자의 session에 추가합니다.
• 이 빈의 속성들에 대응하는 파라미터에 대해, 대응되는 setter메소드를 호출합니다. 이 동작들은 어떤 의미로는 모든 속성들을 선택하기 위해 * 와일드카드를 사용하는 표준 JSP action <jsp:setProperty> 와 비슷합니다.
• 갱신된 ActionForm빈은 Action 클래스의 perform() 메소드에게 전달되고, perform() 메소드에 의해 호출되고, 사용 가능한 값들을 만들게 됩니다.

ActionForm빈들을 코딩할때, 다음의 원칙들을 명심해서 따르도록 합니다.

• ActionForm 클래스 자체는 어떤 특정한 메소드를 구현하는 것을 요구하지 않습니다. 그것은 전체 아키텍쳐에서 각각의 빈들이 수행하는 역할을 명시하기 위해 사용됩니다. 전형적으로, ActionForm 빈은 비지니스 로직없이 속성의 getter, setter 메소드만을 가집니다.
• 또한 ActionForm 오브젝트는 표준적인 검증 메커니즘을 제공합니다. "stub" 메소드를 오버라이드 하고, 에플리케이션 리소스에 에러 메시지를 추가하면, Struts는 자동으로 form의 input을 (오버라이드한 메소드로) 검증합니다. 자세한 것은 "Action Form 검증"을 참고하시길 바랍니다. 물론 ActionForm 검증을 사용하지 않고 Action 오브젝트 내에 고유한 검증 방법을 추가할 수도 있습니다.
• form에 있는 각 input 필드에 대한 속성을 정의합니다.(관련된 getXxx()와 setXxx()메소드들과 함께) form 필드 이름과 속성의 이름은 항상 JavaBeans 규약에 따라 반드시 매칭되어야 합니다. 예를 들어 username이라는 이름의 input 필드는 setUsername() 메소드를 호출하게 될 것 입니다.
• ActionForm 빈을 HTTP와 Action사이의 firewall이라고 생각야합니다. 요구되는 모든 속성의 상태와 적합한 값임을 확인하기 위해 validate 메소드를 사용합니다. 검증에 실패한 ActionForm은 Action에서 처리 되지 않을 것 입니다.
• form에 빈 인스턴스(bean instance)를 놓을 수도 있고, 중첩된 속성 레퍼런스도 사용할 수 있습니다. 예를 들어, Action Form상에서 "customer" 빈을 가진다면, JSP view에서 "customer.name" 속성을 참조할 수 있습니다. 이는 customer빈의 customer.getName()와 customer.setName(String name)에 대응합니다. 중첩된 문법에 대한 보다 자세한 내용은 Tag 라이브러리 개발자 가이드를 보시기 바랍니다.
• 주의: 만일 존재하는 빈 인스턴스(bean instance)를 form 상에 입력한다면, 인스턴스의 속성을 생각해야 합니다. ActionForm 상의 모든 public 속성들은 form 내부에서 하나의 String값으로 설정될 수 있습니다. 요구되는 속성만을 드러내는 가벼운 "wrapper"를 빈에 추가하는 것이 좋을 것 입니다. 또한 wrapper는 런타임에 적합하지 않은 속성이 설정되지 않음을 보장하는 필터를 제공할 수도 있습니다.

여기서 논의하고 있는 "form"은 반드시 유저 인터페이스 내에 하나의 JSP페이지에 대응되는 것은 아닙니다. 많은 애플리케이션에서 여러 개의 페이지에 확장된 (유저의 관점에서) 하나의 "form"을 가지는 것은 일반적인 일입니다. 예를 든다면, 보통 새로운 에플리케이션을 인스톨할때 사용되는 마법사 스타일의 유저 인터페이스를 생각해보시기 바랍니다. Struts는 (form의)필드가 어떤 페이지에서 보여진다 할지라도 모든 필드에 대한 속성을 포함하는 하나의 ActionForm빈을 정의할 수 있습니다. 따라서, (편주:같은 ActionForm이라면) 다양한 페이지의 같은 form은 같은 Action 클래스로 submit될 것이다. 만일 이런 제안을 따른다면, 페이지 디자이너는 페이지의 처리 로직을 자주 바꿀 필요없이 다양한 페이지 사이에서 (form)필드들을 재배치할 수 있습니다.