스프링 프레임워크는 J2EE 애플리케이션 개발을 쉽게 해준다는, 매우 특정한 목적을 지니고 세상에 선을 보였다. 이 책 『스프링 인 액션』의 집필 목적도 스프링을 쉽게 사용하는 방법을 가르쳐주기 위함이었다. 하지만 스프링 API를 하나하나 나열해 설명하는 것이 아니라, 실제 경험에서 나온 실전 코드 예제를 제공함으로써 J2EE 개발자에게 가장 적절한 방법으로 스프링 프레임워크를 알려주고자 했다.
스프링은 모듈화된 프레임워크이기 때문에 이 책도 그런 방식을 따랐다. 스프링 프레임워크를 처음부터 철저하게 배우기를 원하는 개발자도 있고, 원하는 주제만을 골라 알아보고 싶은 개발자도 있을 것이다. 이 책은 두 가지 부류의 독자를 모두 만족시킬 수 있도록, 스프링을 처음 공부할 때 필요한 도구로서의 역할뿐만 아니라, 특정한 주제에 대해 깊이 있게 공부할 수 있는 가이드이자 참고서의 역할도 할 것이다.


[ 이 책의 특징 ]

스프링은 자바 분야에 불고 있는 신선한 바람이다. 제어 역행(IoC)이라는 설계 사상을 기초로 하는 스프링은, EJB가 필요치 않은 강력하고도 가벼운 J2EE 프레임워크다. 스프링은 인터페이스를 사용함에 있어서 복잡함을 줄일 수 있으며, 애플리케이션을 쉽고 빠르게 개발할 수 있다. 스프링을 사용하면 EJB에서와 같은 강력함을 얻을 수 있으며, 동시에 EJB가 아닌 경우의 간단 명료함을 유지할 수 있다.
『스프링 인 액션: 오픈소스 자바 IoC/AOP 프레임워크 』에서는 스프링의 근본 사상을 소개하며 신속하게 프레임워크에 대한 실질적인 연구를 시작할 수 있도록 서술하고 있다. 책 전체에 걸쳐 지속적으로 개발되는 예제와 짧은 코드들을 통해, 간단하면서 효과적인 J2EE 애플리케이션을 어떻게 개발할 수 있는지를 보여준다. 선도적인 오픈소스 툴들을 사용해 퍼시스턴스 문제를 해결하는 방법을 알아보고, 유명한 웹 프레임워크와 여러분의 애플리케이션을 통합하는 방법을 살펴본다. 또한 스프링을 사용해 대부분의 기반구조 코드를 관리하는 방법을 통해 중대한 비즈니스 요구사항에 초점을 맞출 수 있게 될 것이다.

주요 내용
♦ 하이버네이트, JDO, 아이바티스, OJB, JDBC를 이용한 퍼시스턴스
♦ 선언적 트랜잭션과 트랜잭션 관리
♦ 스트럿츠, 웹워크, 태피스트리, 벨로시티 등 웹 프레임워크와의 통합
♦ JMS와 EJB 등과 같은 J2EE 서비스로의 접근
♦ AOP를 사용한 횡단 관심사의 처리
♦ 엔터프라이즈 애플리케이션 선행사례

[ 이 책의 구성 ]

『스프링 인 액션: 오픈소스 자바 IoC/AOP 프레임워크』는 3부와 2개의 부록으로 구성된다. 1부, 2부, 3부는 각각 스프링 프레임워크의 일반적인 영역인 핵심 부문, 중간 계층 부문, 웹 계층 부문에 초점을 맞춘다. 각각은 이전 부분의 내용을 토대로 하지만, 동시에 그 자체로서 독립적이기 때문에 처음부터 시작하지 않아도 특정한 주제에 대해 곧바로 파고들 수 있게 구성했다.

1부에서는 스프링 프레임워크의 핵심적인 두 기능인 제어 역행(IoC, inversion of control)과 관점지향 프로그래밍(AOP, aspect-oriented programming)에 대해 다룰 것이다. 1부 내용을 읽고 나면, 이 책 전체에 걸쳐 사용될 스프링의 근본 사상에 대해 이해하게 될 것이다.
1장에서는 IoC와 AOP를 소개하고, 스프링이 이를 어떻게 이용해 자바 애플리케이션 개발을 쉽게 만들어주는지 설명한다. 또한 스프링이 EJB, 스트럿츠, 피코컨테이너 등과 같은 프레임워크들과 어떻게 비교되는지도 설명한다.
2장에서는 IoC를 사용해 애플리케이션을 설정하는 방법을 좀더 자세히 알아본다. 느슨하게 결합하는 컴포넌트를 작성하는 방법과, XML을 사용해 스프링 컨테이너 안에서 그 컴포넌트들의 의존 객체와 특성을 묶는 방법을 공부할 것이다.
3장에서는 스프링 AOP를 사용해 어떻게 보안 등과 같은 횡단 관심사(cross-cutting concern)를 서비스하는 객체로부터 분리시킬 수 있는지 설명한다. 이 내용을 토대로 5장에서는, 스프링 AOP를 사용해 선언적 트랜잭션 서비스를 제공하는 방법을 배우게 될 것이다.

2부에서는 1부에서 소개했던 IoC와 AOP를 기초로, 이들 개념을 애플리케이션의 중간 계층에 어떻게 적용하는지를 알아볼 것이다.
4장은 데이터 퍼시스턴스를 위한 스프링의 지원에 대해 다룬다. JDBC와 관련된 반복적인 코드의 상당 부분을 줄일 수 있는 스프링의 JDBC 지원에 대해 알아 볼 것이다. 또한 하이버네이트, JDO, OJB, 아이바티스 SQL Map과 같은 여러 유명한 객체관계 매핑(ORM) 프레임워크와 스프링과의 통합에 대해 공부할 것이다.
5장은 4장을 보완하는 내용으로서, 스프링의 트랜잭션 지원을 사용해 어떻게 데이터베이스의 무결성을 보장할 수 있는지 설명한다. EJB를 사용하지 않고도 스프링 AOP를 이용해 선언적 트랜잭션의 강력함을 얻을 수 있는 방법을 알게 될 것이다.
6장은 애플리케이션 객체를 원격 서비스로서 공개하는 방법을 설명한다. 또한 원격 서비스가 마치 애플리케이션 내에 존재하는 것처럼 투명하게 원격 서비스에 접근하는 방법도 알아볼 것이다. 알아볼 리모팅 기술에는 RMI, Hessian/Burlap, EJB, 웹 서비스, 스프링 자체의 HttpInvoker가 포함된다. 대부분의 엔터프라이즈 애플리케이션은 홀로 고립되어 존재하지 않기 때문에, 7장에서는 다른 엔터프라이즈 서비스와 연계하는 방법을 설명할 것이다. 7장을 통해 스프링을 사용해 메일 서비스, JMS, EJB 등과 통합하는 방법이 얼마나 쉬운지 알게 될 것이다.

3부에서는 중간 계층을 벗어나, 대부분의 J2EE 애플리케이션에서 사용되는 프레젠테이션 계층인 웹으로 이동한다.
8장은 스프링의 자체 MVC 웹 프레임워크에 대해 소개한다. 어떻게 스프링이 웹 파라미터를 비즈니스 객체에 투명하게 바인딩시키고, 동시에 유효성 검증과 에러 처리 기능을 제공하는지 알게 될 것이다. 또한 스프링의 인터셉터를 사용해 얼마나 쉽게 웹 애플리케이션에 기능을 추가할 수 있는지 보게 될 것이다.
9장은 스프링 MVC의 기본을 바탕으로, JSP를 뛰어 넘어 벨로시티나 프리마커와 같은 템플릿 언어를 사용하는 방법을 보여준다. 또한 스프링 MVC를 사용하여 PDF나 엑셀 문서와 같은 바이너리 컨텐츠를 동적으로 만드는 방법도 공부할 것이다.
10장에서는 다른 웹 프레임워크와 스프링을 통합하는 방법을 보여준다. 이미 여러 프레임워크에 투자해온 사람들을 위해, 스프링은 스트럿츠, 태피스트리, JSF, 웹워크와 같은 다양한 웹 프레임워크에 대해 지원한다.
마지막으로 11장에서는 아씨지 보안 시스템이 제공하는 인증을 사용해 웹 애플리케이션에 보안을 적용하는 방법을 공부할 것이다. 또한 메소드 수준으로 보안을 적용할 수 있도록 아씨지와 비즈니스 객체를 통합하는 방법도 알게 될 것이다.

부록 A는 스프링 프레임워크를 다운로드하는 방법과 앤트 빌드 파일을 설정하는 방법을 보여줌으로써, 여러분만의 스프링 애플리케이션을 시작할 수 있게 할 것이다.
부록 B는 스프링과 관련된 여러 오픈소스 프레임워크들을 소개한다.


[ 이 책의 대상 ]

『스프링 인 액션: 오픈소스 자바 IoC/AOP 프레임워크』는 모든 자바 개발자를 위한 책이지만, 특히 엔터프라이즈 자바 개발자에게 유용할 것이다. 각 장에 걸쳐 점점 복잡해지는 코드 예제를 통해 친절하게 안내할 것이지만, 스프링의 진정한 강력함은 엔터프라이즈 애플리케이션을 쉽게 개발하도록 하는 능력에 있다. 따라서 엔터프라이즈 개발자는 이 책에서 제시하는 예제를 완전히 이해할 수 있을 것이다.
스프링의 상당 부분이 엔터프라이즈 서비스를 제공하는 데 할애됐기 때문에, 스프링과 EJB는 서로 유사한 점이 많을 것이다. EJB를 써본 경험이 있다면 이 두 프레임워크를 비교함에 있어서 유용할 것이다. 마지막으로, 이 책은 웹 애플리케이션에만 다루는 것은 않지만, 상당 부분이 그 주제에 초점을 맞추고 있다. 실제로 마지막 4개 장은 스프링이 애플리케이션의 웹 계층 개발을 어떻게 지원하는지 보여준다. 웹 애플리케이션 개발자라면, 이 책의 마지막 4개 장을 특히 유용하게 활용할 수 있을 것이다.

[ 저자 서문 ]

소프트웨어 개발자가 자신의 기술을 발현하기 위해서는 다양한 덕목이 필요합니다. 그들은 먼저 훌륭한 분석적 사고자와 문제 해결사가 돼야 합니다. 개발자의 주된 역할은 비즈니스의 문제를 해결하는 소프트웨어를 만드는 데 있습니다. 따라서 고객의 요구사항을 분석해서, 성공적이고 창조적인 솔루션을 만들어내야 합니다. 또한 개발자는 호기심이 많아야 합니다. 소프트웨어 산업에서 개발이란 항상 목표를 향해 나아가는 것이며 진화하는 것입니다. 새로운 프레임워크, 새로운 기법, 새로운 언어, 그리고 새로운 방법론이 지속적으로 출현합니다. 모두 개발자가 업무를 더 빠르게, 또 잘 수행하기 위해 숙달해야 할 도구들입니다. 그 다음 가장 소중한 덕목 중의 하나로 “게으름”을 들 수 있습니다. 게으른 개발자는 어떻게 하면 노력을 덜 들이고 일을 할 수 있을까하고 방법을 찾기 위해 애를 씁니다. 4년 전 소프트웨어를 개발하는 새로운 방법을 찾는 것을 실패한 우리 두 사람에게 부족했던 건 ‘호기심’과 ‘게으름’, 그리고 ‘분석 능력’이었습니다.
그 때는 자바 진영에서 오픈소스 소프트웨어가 거의 임계치에 도달한 때였습니다. 무수히 많은 오픈소스 프레임워크가 자바 세계에서 번창했습니다. 뭔가를 채택하려면 정확히 필요에 맞는 부분이 있어야 합니다. 프레임워크에서 최소한 80% 정도는 곧바로 사용할 수 있어야 하고, 바로 사용할 수 없는 나머지 기능들을 위해 쉽게 확장될 수 있어야 합니다. 지저분하다고 느껴질 정도로 어리석게 뜯어고친다는 것이 확장은 아닙니다. 우아한 방법으로 확장할 수 있어야 합니다. 이는 결코 지나친 요구가 아닙니다. 그렇지 않습니까?
그런 프레임워크 중에 우리 팀에서 가장 먼저 채택한 것은 앤트(Ant)였습니다. 자바 애플리케이션을 개발할 때의 고통을 잘 알고 있는 개발자들이 우리를 위해 앤트를 개발했을 것이라는 생각까지 했습니다. 그 순간부터 더 이상 javac는 없었습니다. CLASSPATH도 없었습니다. 그 모든 것은 직관적인(다소 많은 내용이지만) XML 설정 파일에서 이뤄집니다. 만세! 우리의 삶이 (그리고 빌드가) 점점 쉬워지고 있습니다. 시간이 흐르면서 점점 더 많은 툴들을 채택했습니다. 우리가 선택한 IDE는 이클립스였습니다. Log4J는 기본 로깅 툴킷이 됐으며, 또한 루씬으로 상용 검색 솔루션을 대체했습니다. 이 툴들은 사용하기 쉽고, 이해하기 쉽고, 확장하기 쉬워야 한다는 우리 기준을 모두 충족시켰습니다.
그러나 무엇인가가 부족했습니다. 이 훌륭한 툴들은 앤트나 이클립스와 같이 소프트웨어를 개발하는 데 도움이 되도록 설계된 것도 있고, 루씬(검색)이나 Log4J(로깅)와 같은 특별한 목적을 이루기 위한 것도 있습니다. 그러나 정작 어떤 것도 엔터프라이즈 애플리케이션의 핵심, 즉 퍼시스턴스, 트랜잭션, 다른 엔터프라이즈 자원과의 통합에 대해 얘기하는 것은 없었습니다.
그러던 중 작년 들어 상황이 많이 변했습니다. 우리는 스프링과 하이버네이트가 날리는 가공할만한 엔터프라이즈급 펀치를 목격했습니다. 이 두 프레임워크는 애플리케이션의 중간 계층과 데이터 계층에서 필요한 거의 모든 것을 충족시켰습니다. 우리는 먼저 하이버네이트를 채택했습니다. 하이버네이트는 가장 직관적이고 풍부한 기능의 객체관계 매핑(ORM) 툴이었습니다. 그러나 스프링을 채택함으로써 비로소 정말로 좋은 코드를 만들 수 있었습니다. 스프링의 제어 역행(inversion of control)을 사용함으로써 모든 커스텀 팩토리와 설정자를 제거할 수 있었습니다. 사실 이 때문에 애플리케이션에 가장 먼저 스프링을 통합시켰던 것입니다. 스프링의 묶기(wiring)를 사용해 능률적인 애플리케이션의 설정을 할 수 있었으며, 또한 자체 제작한 솔루션으로부터도 벗어날 수 있었습니다(모든 개발자는 자신만의 프레임워크를 만들고 싶을 것입니다. 그러나 그렇게 할 수 없는 경우도 많습니다).
멋진 보너스도 있었습니다. 스프링이 하이버네이트와 매우 쉽게 통합할 수 있는 기능을 지원하는 것이었습니다. 이로써 우리가 자체적으로 만든 하이버네이트 통합 클래스를 버리고 스프링이 제공하는 것을 사용할 수 있었습니다. 즉, 우리는 투명한 퍼시스턴스를 위한 스프링의 지원 기능을 직접 사용할 수 있었던 것입니다.
자세히 보면 여기서 어떤 패턴을 발견할 수 있을 것입니다. 스프링을 사용하면 할수록 새로운 기능들을 더 많이 찾아낼 수 있었습니다. 그리고 발견한 각 기능들을 기쁘게 사용할 수 있었습니다. 스프링의 웹 MVC 프레임워크는 애플리케이션에서 훌륭하게 작동했습니다. 스프링의 AOP 지원은 여러 곳, 특히 보안과 관련하여 유용하게 사용할 수 있었습니다. 스프링의 JDBC 지원은 작은 프로그램들에서도 유용했습니다. 아, 우리는 스프링을 스케줄링에도 이용했습니다. JNDI 접근에도 이용했고, 이메일 통합에도 이용했습니다. 우리가 개발이라는 야구방망이를 휘두르면, 스프링은 공을 경기장 밖으로 멀리 날려줬습니다.
우리가 스프링을 아주 좋아했기 때문에, 사람들은 스프링과 관련된 책을 써야 한다고 생각했습니다. 다행히도 우리 중에 한 명이 이미 매닝 출판사에서 책을 쓴 경험이 있었고, 그런 종류의 일을 어떻게 하는지 알고 있었습니다. “책을 써야 하는 누구”는 곧 우리가 됐습니다. 이 프로젝트를 진행하면서 우리는 스프링의 복음을 널리 전하려고 노력했습니다. 스프링 프레임워크는 즐거움 그 자체였고 여러분도 그렇게 느끼게 될 것이라고 믿습니다. 또한 이 책이 여러분을 그 지점까지 데려다 주는 즐거운 자동차가 되기를 희망합니다.


[ 저자 소개 ]

크렉 월즈
Craig Walls는 통신, 유통, 전자상거래 분야에서 10년 이상 소프트웨어 솔루션을 개발한 경험이 있는 프로 소프트웨어 개발자다. 그는 각종 유저 그룹과 컨퍼런스에 자주 초청되며, 『XDoclet in Action』의 공저자이기도 하다. 크렉은 텍사스주 덴튼에 살고 있다.

라이언 브라이덴바흐
Ryan Breidenbach는 오픈소스 자바 기술의 열렬한 지지자로서 #지난 5년간 자바 웹 애플리케이션을 개발해왔다. 라이언은 텍사스주 코펠에 살고 있다.


[ 역자 서문 ]

제가 스프링 프레임워크를 처음 알게 된 때는 2004년 봄 즈음 TheServerSide.COM을 통해서였던 것으로 기억합니다. 그 당시 자바 세계에는 이미 자카르타 스트럿츠를 선두로 수많은 프레임워크들이 난무해 있었습니다. 제어 역행(IoC, Inversion of Control)과 관점지향 프로그래밍(AOP, Aspect-Oriented Programming)은 실제 프로젝트에 적용하기는 아직 요원한 일로 보였으며, 스프링은 또 하나의 새로운 프레임워크일 뿐이라 여기고 관심을 두지 않았었습니다.
그 후 자바 세계는 계속 변화했고, 커다란 변화들 중 하나의 중심에는 스프링이 있었습니다. IoC에 대한 지원은 이제 자바 프레임워크가 갖춰야 할 중요한 기능 중 하나가 됐으며, AOP는 OOP의 대를 잇는 패러다임이자 프로그래밍의 새로운 발전 방향으로 자리잡게 됐습니다. 이제 스프링은 스트럿츠와 함께 J2EE 개발 프레임워크의 양대 산맥으로 우뚝 서게 됐다고 해도 과언이 아닐 것입니다.
스프링은 기존의 프레임워크들과 마찬가지로 편리한 J2EE 애플리케이션 개발을 목표로 합니다. 그러나 더 중요한 것은 그런 개발 편리성과 생산성을 가능케 하는 원천이 바로 IoC와 AOP로 인한 유연성과 확장성에 있으며, 이는 스프링이 단순히 개념과 이론에 머물렀던 기술을, 엔지니어들이 손에 잡을 수 있는 실질적인 구현체로 제공했기 때문에 가능해진 것입니다.
이 책 『스프링 인 액션: 오픈소스 자바 IoC/AOP 프레임워크』는 실질적인 예제를 완성해가는 과정을 통해 스프링의 거의 모든 기능을 다루고 있습니다. 그러나 앞서 말했듯이 스프링이 제공하는 기능들을 습득하고 사용법을 익히는 것도 이 책의 장점이지만, 이 책을 통해 어떻게 IoC와 AOP가 여러분의 애플리케이션에 거의 완벽한 유연성과 확장성을 보장해 줄 수 있는지의 근본 원리를 이해하는 것이 가장 중요하다고 할 수 있습니다. 스프링이야말로 많은 아키텍트들과 개발자들이 진정으로 원했던 객체 수준의 분리(느슨한 결합이 아닌 완전한 분리)와 애플리케이션 로직과 시스템 로직의 분리를 가능케 하며, 이 책은 예제를 통해 그와 같은 원리를 자연스럽게 체득할 수 있게 해줍니다. 스프링이 수많은 타 솔루션이나 J2EE 기술과 통합해 사용할 수 있는 이유가 여기에 있습니다.
원서에서 기준으로 하고 있는 스프링의 버전은 1.1.3이며, 번역서는 크게 바꿔야 되는 부분이 없다면 가급적 1.2.7을 기준으로 했습니다. 아쉽게도 이 책이 발간되기 직전인 2006년 10월에 스프링 2.0이 발표됐습니다. 스프링 2.0에는 IoC 컨테이너와 AOP 컨테이너에 몇 가지 편리한 기능들이 추가됐으며, 좀더 많은 타 솔루션과의 통합을 지원합니다. 그러나 그에 따른 API가 바뀌고 추가되었을 뿐, 스프링의 사용법이나 근본 사상에는 전혀 변함이 없다는 사실을 말씀 드리고 싶습니다.
또한 스프링, 특히 AOP 등과 관련해 기존에 잘 사용하지 않던 새로운 용어들이 많이 등장합니다. 이런 용어들의 한글화에 있어서 불가피하게 제 주관이 많이 들어갈 수밖에 없었으며, 따라서 다소 어색하거나 무리한 것처럼 보이는 부분도 있을 수 있다고 생각합니다. 하지만 원어를 무작정 표기하는 것을 피하고 본 뜻을 살리고자 노력한 것임을 독자 여러분께서 이해해주시기 바랍니다.


[ 역자 소개 ]

이태상 taesang@gmail.com
다년간 J2EE/WebSphere 전문가로 활동했으며, 현재는 금융권 차세대시스템 구축 프로젝트에 참여하고 있다. 저서 및 역서로는 『Practical EJB Programming with IBM WebSphere』(2002, 이인티그레이션), 『톰캣 최종분석』(2005, 에이콘), 『JSF 인 액션』(2006, 에이콘)이 있다.

목차

• 1부 스프링의 기본
  
• 1장 스프링 시작하기
  • 1.1 왜 스프링인가?
    • [1.1.1] J2EE 개발자의 일상
    • [1.1.2] 스프링의 공약
  • 1.2 스프링이란?
    • [1.2.1] 스프링 모듈
  • 1.3 스프링 시작하기
  • 1.4 제어 역행의 개념
    • [1.4.1] 의존성 주입
    • [1.4.2] 실전 IoC
    • [1.4.3] 엔터프라이즈 애플리케이션에서의 IoC
  • 1.5 관점지향 프로그래밍의 적용
    • [1.5.1] AOP 소개
    • [1.5.2] 실전 AOP
    • [1.5.3] 엔터프라이즈 AOP
  • 1.6 스프링의 대안
    • [1.6.1] 스프링과 EJB의 비교
    • [1.6.2] 다른 경량 컨테이너에 대한 고려
    • [1.6.3] 웹 프레임워크
  • 1.7 요약
    
• 2장 빈 묶기
  • 2.1 컨테이너 안의 빈
    • [2.1.1] 빈 팩토리 개요
    • [2.1.2] 애플리케이션 컨텍스트로 작업하기
    • [2.1.3] 빈의 일생
  • 2.2 기본 묶기
    • [2.2.1] XML로 묶기
    • [2.2.2] 빈 추가
    • [2.2.3] 세터 메소드를 통한 의존성 주입
    • [2.2.4] 생성자를 통한 의존성 주입
  • 2.3 자동 묶기
    • [2.3.1] 자동 묶기의 모호성 다루기
    • [2.3.2] 명시적 묶기와 자동 묶기의 혼용
    • [2.3.3] 자동 묶기를 기본으로 설정
    • [2.3.4] 자동 묶기를 할 것인가 말 것인가
  • 2.4 스프링의 스페셜 빈으로 작업하기
    • [2.4.1] 빈의 후처리
    • [2.4.2] 빈 팩토리의 후처리
    • [2.4.3] 설정 정보의 외부화
    • [2.4.4] 특성 편집기 커스터마이징
    • [2.4.5] 텍스트 메시지 분석
    • [2.4.6] 이벤트 청취
    • [2.4.7] 이벤트 발행
    • [2.4.8] 인식할 수 있는 빈 만들기
  • 2.5 요약
    
• 3장 애스펙트 만들기
  • 3.1 AOP 소개
    • [3.1.1] AOP 용어 정의
    • [3.1.2] 스프링의 AOP 구현
  • 3.2 충고 생성
    • [3.2.1] 사전 충고
    • [3.2.2] 사후 충고
    • [3.2.3] 주변 충고
    • [3.2.4] 예외 충고
    • [3.2.5] 도입 충고
  • 3.3 교차점 정의
    • [3.3.1] 스프링에서의 교차점 정의
    • [3.3.2] 충고자의 이해
    • [3.3.3] 정적 교차점
    • [3.3.4] 동적 교차점
    • [3.3.5] 교차점 조작
  • 3.4 도입 충고 생성
    • [3.4.1] IntroductionInterceptor 구현
    • [3.4.2] IntroductionAdvisor 생성
    • [3.4.3] 도입 충고 사용시의 주의점
  • 3.5 ProxyFactoryBean
  • 3.6 오토프록시
    • [3.6.1] BeanNameAutoProxyCreator
    • [3.6.2] DefaultAdvisorAutoProxyCreator
    • [3.6.3] 메타데이터 오토프록시
  • 3.7 요약
    
    
• 2부 비즈니스 계층에서의 스프링
  
• 4장 데이터베이스 공략
  • 4.1 스프링의 DAO 철학
    • [4.1.1] 스프링의 DataAccessException
    • [4.1.2] DataSource로 작업하기
    • [4.1.3] 일관된 DAO 지원
  • 4.2 스프링에서의 JDBC
    • [4.2.1] JDBC 코드의 문제점
    • [4.2.2] JdbcTemplate
    • [4.2.3] 데이터베이스 작업의 객체화
    • [4.2.4] 자동 증분 키
  • 4.3 스프링의 ORM 프레임워크 지원 기능
  • 4.4 하이버네이트와의 연계
    • [4.4.1] 하이버네이트 개요
    • [4.4.2] 하이버네이트 자원 관리
    • [4.4.3] HibernateTemplate을 통한 하이버네이트로의 접근
    • [4.4.4] HibernateDaoSupport 확장
  • 4.5 스프링과 JDO
    • [4.5.1] JDO 설정
    • [4.5.2] JdoTemplate을 통한 데이터 접근
  • 4.6 스프링과 아이바티스
    • [4.6.1] 데이터 매퍼 설정
    • [4.6.2] SqlMapClientTemplate
  • 4.7 스프링과 OJB
    • [4.7.1] OJB의 PersistenceBroker 설정
  • 4.8 요약
    
• 5장 트랜잭션 관리
  • 5.1 트랜잭션
    • [5.1.1] 트랜잭션의 특성
    • [5.1.2] 스프링 트랜잭션 관리 지원
    • [5.1.3] 스프링 트랜잭션 관리자
  • 5.2 스프링에서의 트랜잭션 프로그래밍
  • 5.3 트랜잭션 선언
    • [5.3.1] 트랜잭션 속성의 이해
    • [5.3.2] 간단한 트랜잭션 정책 선언하기
  • 5.4 메소드 이름으로 트랜잭션 선언
    • [5.4.1] NameMatchTransactionAttributeSource
    • [5.4.2] 이름에 부합하는 트랜잭션
  • 5.5 메타데이터를 사용한 트랜잭션 선언
    • [5.5.1] 메타데이터로부터 트랜잭션 속성 조달
    • [5.5.2] 커먼스 어트리뷰츠를 사용하는 트랜잭션 선언
  • 5.6 트랜잭션 선언 다듬기
    • [5.6.1] TransactionProxyFactoryBean으로부터의 상속
    • [5.6.2] 트랜잭션에 대한 오토프록시
  • 5.7 요약
    
• 6장 리모팅
  • 6.1 스프링 리모팅 개요
  • 6.2 RMI로 작업하기
    • [6.2.1] RMI 서비스 묶기
    • [6.2.2] RMI 서비스 공개
  • 6.3 Hessian과 Burlap을 사용한 리모팅
    • [6.3.1] Hessian/Burlap 서비스로의 접근
    • [6.3.2] Hessian/Burlap 서비스 공개
  • 6.4 HTTP 호출자
    • [6.4.1] HTTP를 통한 서비스 접근
    • [6.4.2] HTTP 서비스로서 빈 공개
  • 6.5 EJB로 작업하기
    • [6.5.1] EJB로의 접근
    • [6.5.2] 스프링을 적용한 EJB 개발
  • 6.6 JAX-RPC 웹 서비스
    • [6.6.1] JAX-RPC를 사용한 웹 서비스 참조
    • [6.6.2] 스프링에서의 웹 서비스 묶기
  • 6.7 요약
    
• 7장 엔터프라이즈 서비스 접근
  • 7.1 JNDI로부터의 객체 취득
    • [7.1.1] 전통적인 방법의 JNDI 작업
    • [7.1.2] JNDI 객체의 프록시화
  • 7.2 이메일 전송
  • 7.3 작업 스케줄링
    • [7.3.1] 자바의 Timer를 사용한 스케줄링
    • [7.3.2] 쿼츠 스케줄러
    • [7.3.3] 스케줄의 메소드 호출
  • 7.4 JMS를 사용한 메시지 전송
    • [7.4.1] JMS 템플릿을 사용한 메시지 전송
    • [7.4.2] 메시지 소비
    • [7.4.3] 메시지 변환
  • 7.5 요약
    
    
• 3부 웹 계층에서의 스프링
  
• 8장 웹 계층 구축
  • 8.1 스프링 MVC로 시작하기
    • [8.1.1] 요청 생명주기
    • [8.1.2] DispatcherServlet 설정
    • [8.1.3] 스프링 MVC 핵심 요약
  • 8.2 요청과 컨트롤러와의 매핑
    • [8.2.1] URL과 빈 이름과의 매핑
    • [8.2.2] SimpleUrlHandlerMapping
    • [8.2.3] 컨트롤러 매핑을 위한 메타데이터 사용
    • [8.2.4] 다수의 핸들러 매핑 사용하기
  • 8.3 컨트롤러를 사용한 요청 처리
    • [8.3.1] 단순한 컨트롤러 작성
    • [8.3.2] 명령 처리
    • [8.3.3] 폼 제출 처리
    • [8.3.4] 마법사를 통한 복잡한 폼의 처리
    • [8.3.5] 단일 컨트롤러에서 다중 액션 처리하기
    • [8.3.6] 일회성 컨트롤러
  • 8.4 뷰의 결정
    • [8.4.1] 템플릿 뷰의 사용
    • [8.4.2] 뷰 빈 결정
    • [8.4.3] 뷰 리졸버 선택
  • 8.5 스프링 bind 태그
  • 8.6 예외 처리
  • 8.7 요약
    
• 9장 뷰 계층 대안기술
  • 9.1 벨로시티 템플릿
    • [9.1.1] 벨로시티 뷰 정의
    • [9.1.2] 벨로시티 엔진 설정
    • [9.1.3] 벨로시티 뷰 결정
    • [9.1.4] 날짜와 숫자 포맷
    • [9.1.5] 요청과 세션 속성의 공개
    • [9.1.6] 폼 필드 바인딩
  • 9.2 프리마커
    • [9.2.1] 프리마커 뷰 구축
    • [9.2.2] 프리마커 엔진 설정
    • [9.2.3] 프리마커 뷰 결정
    • [9.2.4] 폼 필드 바인딩
  • 9.3 타일즈를 사용한 페이지 레이아웃
    • [9.3.1] 타일즈 뷰
    • [9.3.2] 타일즈 컨트롤러
  • 9.4 HTML이 아닌 출력물 생성
    • [9.4.1] 엑셀 스프레드시트 생성
    • [9.4.2] PDF 문서 생성
    • [9.4.3] HTML 외의 문서 생성
  • 9.5 요약
    
• 10장 다른 웹 프레임워크와의 통합 작업
  • 10.1 자카르타 스트럿츠
    • [10.1.1] 스프링 플러그인 등록
    • [10.1.2] 스프링 인식 액션 구현
    • [10.1.3] 액션 위임
  • 10.2 태피스트리
    • [10.2.1] 태피스트리 엔진 대체
    • [10.2.2] 스프링 빈을 태피스트리 페이지로 로딩하기
  • 10.3 JSF
    • [10.3.1] 변수 결정
    • [10.3.2] 요청 처리 이벤트의 발행
  • 10.4 웹워크
    • [10.4.1] 웹워크 1
    • [10.4.2] 엑스워크/웹워크 2
  • 10.5 요약
    
• 11장 스프링 애플리케이션 보안
  • 11.1 아씨지 보안 시스템의 소개
    • [11.1.1] 보안 인터셉터
    • [11.1.2] 인증 관리자
    • [11.1.3] 접근 결정 관리자
    • [11.1.4] 위임 관리자
  • 11.2 인증 관리
    • [11.2.1] ProviderManager 설정
    • [11.2.2] 데이터베이스를 통한 인증
    • [11.2.3] LDAP 저장소를 사용한 인증
    • [11.2.4] 아씨지와 CAS를 사용한 단일 사인온 구현
  • 11.3 접근 제어
    • [11.3.1] 접근 결정 표결 붙이기
    • [11.3.2] 투표 방식 결정
    • [11.3.3] 투표 회피의 처리
  • 11.4 웹 애플리케이션 보안
    • [11.4.1] 아씨지 필터의 프록시화
    • [11.4.2] 웹 보안 강제하기
    • [11.4.3] 로그인 처리
    • [11.4.4] 보안 컨텍스트 설정
    • [11.4.5] 보안 채널 확인
    • [11.4.6] 아씨지 태그 라이브러리
  • 11.5 메소드 호출 보안
    • [11.5.1] 보안 애스펙트 생성
    • [11.5.2] 메타데이터를 사용한 메소드 보안
  • 11.6 요약
    
• 부록 A 스프링 설치
  • A.1 스프링 다운로드
  • A.2 배포본 선택
  • A.3 프로젝트 설정
  • A.4 앤트로 빌드하기
    
• 부록 B 스프링 관련 프로젝트
  • B.1 AppFuse
  • B.2 스프링 리치 클라이언트

[ p.32 4행 ]
public StudentService → public interface StudentService

[ p.43 1행 ]
함참동안 → 한참동안

[ p.45 첫 번째 코드 2행 ]
FileInputStream → FileSystemResource

[ p.78 코드 4행 ]
<valuejdbc:hsqldb:Training</value>
→ <value>jdbc:hsqldb:Training</value>

[ p.81 첫 번째 코드 1행 ]
public Contact { → public class Contact {

[ p.81 두 번째 코드 1행 ]
public PhoneNumber { → public class PhoneNumber {

[ p.96 5번째 문단 2행 ]
이 서브클래스 생성시킴으로써 → 이 서브클래스를 생성시킴으로써

[ p.98 표 3.1 사전 충고 행, 인터페이스 열 ]
org.springframework.aop.BeforeAdvice → org.springframework.aop.MethodBeforeAdvice

[ p.109 9행 ]
frequentCustomerAdvisor → frequentCustomerPointcutAdvisor

[ p.110 리스트 3.8 3행 ]
MaidService → MaidServiceImpl

[ p.123 2번째 코드 4행 ]
<bean class “com.springinaction.training.
→ <bean class= “com.springinaction.training.

[ p.124 두 번째 코드 1행 ]
<property name="proxyInterfaces">
→ <property name="interceptorNames">

[ p.147 아래에서 11번째 행 ]
execute(String sql, Object[] params)
→ update(String sql, Object[] params)

[ p.148 5행 ]
execute()를 수행하는 모습을 보여준다.
→ update()를 수행하는 모습을 보여준다.

[ p.148 리스트 4.7 ]
리스트 4.7 JdbcTemplate.execute 메소드를 사용한 데이터 삽입
→ 리스트 4.7 JdbcTemplate. update 메소드를 사용한 데이터 삽입

[ p.153 코드 5행 ]
“values (?, ?, ?)”;
→ “values (?, ?, ?)” );

[ p.178 그림 5.2 ]


[ p.185 표 5.2 ]
'PROPAGATION_MANDATORY'행 '의미'열
만약 기존의 트랜잭션이 진행중이라면 예외가 던져질 것이다.
→ 만약 기존의 트랜잭션이 존재하지 않는다면 예외가 던져질 것이다.

[ p.193 마지막 행 ]
양수 기호(-)
→ 양수 기호(+)

[ p.229 6행 ]
paymentService → payService

[ p.287 12행 ]
ListCoursesController”
→ listCoursesController”

[ p.301 리스트 8.7 11행 ]
ByNameComparator() → ByDateComparator()

[ p.351 ‘스프링 빈으로서 액션 묶기’ 절 코드 아래 1행 ]
XML은 id 속성에 사하지 않기 때문이다.
→ XML은 id 속성에 사용할 수 있는 문자들에 제한을 두고 있으며 슬래시(/)의 경우 유효하지 않기 때문이다.