[스프링 인 액션(제4판)]_오탈자

현재까지 발견된 위 책의 오탈자 정보와 오류, 그리고 보다 매끄러운 문장을 위해 수정한 내용을 안내해드립니다. 번역과 편집 시에 미처 확인하지 못하고 불편을 끼쳐드려 죄송하다는 말씀을 드립니다. 아래의 오탈자 사항은 추후 재쇄 시에 반영하도록 하겠습니다. 

이외의 오탈자 정보를 발견하시면 역자(asinayo73@hotmail.com)나 출판사(jeipub@gmail.com)로 연락주시면 고맙겠습니다.

최종수정일자: 2019년 1월 13일

1-3쇄본 오탈자

407쪽 가운데 부분에서(고O광 님 제보)

MongoOperations는 MongoTemplate 구현 인터페이스며, 주입 시 구체적 구현물로 직접 사용되지 않는 형태를 가진다.

==>

MongoOperations는 MongoTemplate이 구현한 인터페이스이며, 주입 시 구체적 구현물을 직접 사용하지 않는 게 좋다.

413쪽 코드 12.7 중간 부분에서(원서 오류)(고O광 님 제보)

    Criteria where = Criteria.where("type").is(t);

==>

    Criteria where = Criteria.where("type").is(type);

414쪽 12.2절 위쪽 두 번째 문단에서(고O광 님 제보)

특정 클래스의 문제점을 해결할 수 있지만,

==>

특정 분야의 문제점을 해결할 수 있지만,

419쪽 코드 12.10 제목에서(고O광 님 제보)

Order는 그래프 데이터베이스에서 노드로 애너테이션되지 않는다.

==>

Order는 그래프 데이터베이스에서 노드로 애너테이션된다.

429쪽 하단에서 6번째 행에서(고O광 님 제보)

영속적인 해시 맵을 호출하기 위한 과도한 단순화는 너무 많이 할 필요는 없다.

==>

그것들을 영구(영속)적인 해시 맵이라고 부르는 것은 지나치게 단순하지는 않을 것이다.

440쪽 마지막 문단 1행에서(고O광 님 제보)

빈의 캐싱 애너테이션 적용 전에는 스프링의 애너테이션 주도 캐싱 지원을 사용해야 한다.

==>

빈에 캐싱 애너테이션을 적용하기에 앞서, 애너테이션 주도 캐싱을 위해 스프링 캐쉬 설정(지원)을 활성화해야 한다.

441쪽 하단에서 세 번째 문단 1행에서(고O광 님 제보)

코드 13.1과 코드 13.2 둘다 애너테이션 주도 캐싱보다 더 활성화된 것을 보았을 것이다.

==>

코드 13.1과 코드 13.2 모두가 애너테이션 주도 캐싱을 활성화하는 것보다 더 많은 것을 한다는 것을 알고 있을 것이다.

452쪽 13.2.2절 두 번째 문단 3행에서(고O광 님 제보)

데이터가 삭제되었을 때가 이런 경우에 속한다. 이와 같은 경우 데이터가 삭제된 것이다.

==> 

데이터가 삭제되었을 때가 이런 경우에 속한다.

452쪽 가운데 NOTE의 3-4행에서(고O광 님 제보)

그러나 @CacheEvict가 캐시에서 아이템을 제거만 하므로, 심지어 void이더라도 다른 메소드에서 존재된다.

==> 

그러나 @CacheEvict가 캐시에서 아이템을 제거만 하므로 다른 어떤 메소드에도, 심지어 void에도 적용할 수 있다.

453쪽 1-2행에서(고O광 님 제보)

알다시피 @CacheEvict는 @Cacheable, @CachePut과 동일한 애트리뷰트 일부를 새 애트리뷰트와 함께 공유한다.

==> 

보다시피 @CacheEvitect는 @Cacheable 및 @CachePut과 동일한 애트리뷰트 중 일부를 공유하며, 몇 가지 새로운 애트리뷰트도 공유한다.

453쪽 하단에서 두 번째 문단 2행에서(고O광 님 제보)

스프링의 캐시 네임스페이스는 애니테이션 지향 캐싱에 대한 대안으로서

==>

스프링의 캐시 네임스페이스는 애너테이션 지향 캐싱에 대한 대안으로서

68쪽 1-2행에서(고O광 님 제보)

일반적으로, 어떤 종속성으로 인해 하드 의존성 및 프로퍼티 주입을 위한 생성자 주입이 선호된다.

==>

일반적인 규칙에 따라 나는 하드 의존성에 대해서는 생성자 주입과 옵션 의존성에 대해서는 프로퍼티 주입을 선호한다.

71쪽 두번째 행에서(고O광 님 제보)

tranks 속성을 ==> tracks 속성을

74쪽 두 번째 문단 1행에서(고O광 님 제보)

@import를 남길 수 있다.

==>

@Import를 남길 수 있다.

135쪽 코드 4.2에서 들여쓰기 이슈(고O광 님 제보)

  @Before("performance()")    <== 공연 이전

  public void silenceCellPhones() {

    System.out.println("Silencing cell phones");

} 

==>

  @Before("performance()")    <== 공연 이전

  public void silenceCellPhones() {

    System.out.println("Silencing cell phones");

  } 

138쪽 코드 4.5에서 행바꿈 이슈(고O광 님 제보)

      System.out.println("Silencing cell phones"); System.out.println("Taking seats");

==>

      System.out.println("Silencing cell phones");

      System.out.println("Taking seats");

138쪽 마지막 문단 2-3행에서(고O광 님 제보)

그러나, 네 가지 어드바이스 메소드에 효과가 적용되기 이전에는 한 가지 어드바이스 메소드에만 효과가 적용된다.

==>

그러나 전에 네가지 어드바이스 메소드로 나눠서 적용했던 것을 한 가지 어드바이스 메소드로 모두 적용이 가능하다.

139쪽 세 번째 문단 2행에서(고O광 님 제보)

여러 번 호출한다는 사실이다.

==>

여러 번 호출할 수 있다는 사실이다.

146쪽 표 4.3 제목에서(고O광 님 제보)

스프링 AOP 설정 요소의 급속적인 애스펙트 활성화

==>

스프링 AOP 설정 요소의 비 급속적인(non-invasive) 애스펙트 활성화

147쪽 1-2행에서(고O광 님 제보)

여기서 살펴보았듯이 AspectJ 애너테이션을 사용한 것 외에 Audience 클래스에 특별한 것은 없다.

==>

여기서 살펴보았듯이, AspectJ 애너테이션을 사용하지 않은 것 말고는 Audience 클래스에 특별한 것은 없다.

155쪽 코드 4.15에서 들여쓰기 및 줄바꿈 이슈(고O광 님 제보)

package concert; public aspect CriticAspect {

public CriticAspect() {}

  pointcut performance() : execution(* perform(..));

==>

package concert; 

public aspect CriticAspect {

  public CriticAspect() {}

  pointcut performance() : execution(* perform(..));

501쪽 맨 밑(원서 오류)(고O광 님 제보)

  exporter.setBaseAddress("http://localhost:8888/services/");

}

==>

  exporter.setBaseAddress("http://localhost:8888/services/");

  return exporter;

}

502쪽 그림 15.10에서(고O광 님 제보)

Hessian/Burlap

FactoryBean

==>

JaxWsPortProxy

FactoryBean

508쪽 다섯 번째 블릿 기호에서(고O광 님 제보)

뷰 기반의 렌더링은 새로운 @ResponseBody 애너테이션과 다양한 HttpMethodConverter 구현체를 이용해 모두 무시한다.

==>

뷰 기반의 렌더링은 @ResponseBody 애너테이션과 다양한 HttpMethodConverter 구현체를 이용해 모두 무시할 수 있다.

522쪽 코드 박스에서(원서 오류)(고O광 님 제보)

method=RequestMethod.POST

==>

method=RequestMethod.POST,

530쪽 코드 박스에서(원서 오류)(고O광 님 제보)

    method=RequestMethod.POST

==>

    method=RequestMethod.POST,

531쪽 코드 박스에서(원서 오류)(고O광 님 제보)

    method=RequestMethod.POST

==>

    method=RequestMethod.POST,

532쪽 코드 박스에서(원서 오류)(고O광 님 제보)

    method=RequestMethod.POST

==>

    method=RequestMethod.POST,

525쪽 중간 부분 문장에서(고O광 님 제보)

이제 시나리오에서 무엇이 발생해야 하는지 생각해 보자. 최소한 상태 코드는 200이 되면 안 된다. 이는 클라이언트에게 요청한 것을 찾을 수 없다는 것을 말하기 위해 404(Not Found)가 되어야 한다. 그리고 응답 보디는 비어 있는 대신에 에러 메시지를 가진다.

• 스프링은 해당 시나리오를 수행하기 위해 몇 개의 옵션을 제공한다.
• 상태 코드는 @ResponseStatus 애너테이션으로 지정된다.
• 컨트롤러 메소드는 응답에 관한 많은 메타데이터를 가지는 ResponseEntity를 반환한다.

예외 핸들러는 다수의 에러 케이스들을 처리할 수 있으며, 원하는 경로에 집중하기 위해서 핸들러 메소드를 사용하지 않는다. 스프링이 다양한 유연성을 제공하지만, 여기에서 정확한 접근법으로 진행하는 것은 없다. 이러한 종류의 에러를 처리하거나, 모든 가능한 시나리오를 커버하도록 하기 위한 단일 전략으로 좁혀가려 하는 대신에 Spittle에서 발견할 수 없는 경우를 처리하기 위해 spittleById( )를 변경하는 여러 방법을 제시한다.

==>

이제 시나리오에서 무엇이 발생해야 하는지 생각해 보자. 최소한 상태 코드는 200이 되면 안 된다. 이는 클라이언트에게 요청한 것을 찾을 수 없다는 것을 말하기 위해 404(Not Found)가 되어야 한다. 그리고 응답 보디는 비어 있는 대신에 에러 메시지를 가진다.

스프링은 해당 시나리오를 수행하기 위해 몇 개의 옵션을 제공한다.

• 상태 코드는 @ResponseStatus 애너테이션으로 지정된다.
• 컨트롤러 메소드는 응답에 관한 많은 메타데이터를 가지는 ResponseEntity를 반환한다.
• 예외 핸들러는 다수의 에러 케이스들을 처리할 수 있으며, 원하는 경로에 집중하기 위해서 핸들러 메소드를 사용하지 않는다. 

스프링이 다양한 유연성을 제공하지만, 여기에서 정확한 접근법으로 진행하는 것은 없다. 이러한 종류의 에러를 처리하거나, 모든 가능한 시나리오를 커버하도록 하기 위한 단일 전략으로 좁혀가려 하는 대신에 Spittle에서 발견할 수 없는 경우를 처리하기 위해 spittleById( )를 변경하는 여러 방법을 제시한다.

534쪽 하단 4행에서(고O광 님 제보)

TRACE의 예외를 이용해 RestTemplate은 모든 HTTP 동사를 다룬다.

==>

RestTemplate은 TRACE를 제외한 모든 HTTP 동사를 다룬다.

638쪽 첫 번째 문단 3-4행에서(고O광 님 제보)

HomeController MBean의 경우는 pair.spitter:name=SpittleController가 된다.

==>

SpittleController MBean의 경우는 spitter:name=SpittleController가 된다.

638쪽 하단 3행에서(고O광 님 제보)

showHomePage() 메소드를 호출하거나

==>

spittles() 메소드를 호출하거나

644쪽 상단 3행에서(고O광 님 제보)

HomeController를 변경하는

==>

SpittleController를 변경하는

646쪽 하단 2행에서 (고O광 님 제보)

HomeController MBean을

==>

SpittleController MBean을

649쪽 하단 2행에서(고O광 님 제보)

다음은 HomeController

==>

다음은 SpittleController

650쪽 하단 3행에서(고O광 님 제보)

HomeControllerMBean이 설정되어 있다.

==>

SpittleController MBean이 설정되어 있다.

651쪽 상단 2행에서(고O광 님 제보)

동일한 HomeControllerManagedOperations 인터페이스를

==>

동일한 SpittleControllerManagedOperations 인터페이스를

161쪽 두 번째 문단 2행에서(고O광 님 제보)

스프링 MVC는 스프링 프레임워크 자체와 긴밀한 연결 없이 유연한 웹 기반

==>

스프링 MVC는 스프링 프레임워크 자체만큼이나 유연하고 느슨하게 결합된 웹 기반

163쪽 두 번째 문단 2행에서(고O광 님 제보)

요청들을 깔대기처럼 하나의 프런트

==>

요청들을 하나의 단일 프런트

164쪽 위에서 6번째 줄(고O광 님 제보)

응답(response) 객체 ①

==>

응답(response) 객체 ⑦

179쪽 코드 5.10에서 들여쓰기 수정(고O광 님 제보)

@Autowired

public SpittleController(

    SpittleRepository spittleRepository) {

this.spittleRepository = spittleRepository;

}

==>

@Autowired

public SpittleController(

    SpittleRepository spittleRepository) {

  this.spittleRepository = spittleRepository;

}

187쪽 위에서 1~4번째 줄에서 단어 모두 수정(고O광 님 제보)

spittleID ==>spittleId

202쪽 두 번째 문단 1-2행에서(고O광 님 제보)

이 장의 마무리에서 표 6.1에 없는 뷰 리졸버 옵션들을 살펴보자. 이번 장을 마무리하면서, 표 6.1에 나와 있지 않은 뷰 리졸버를 살펴본다.

==>

이 장의 마무리에서 표 6.1에 없는 뷰 리졸버 옵션들을 살펴보자. 

216쪽 밑에서 두 번째 문단 2행에서(고O광 님 제보)

여기서는 message로 설정한다.

==>

여기서는 messages로 설정한다.

233쪽 세 번째 문단 1행에서(고O광 님 제보)

<input> 태그는 보조객체로부터 firatName 필드를

==>

<input> 태그는 보조객체로부터 firstName 필드를

701쪽 좌측 하단 아래에서 8행에서(고O광 님 제보)

firatName 필드 233

==>

firstName 필드 233

238쪽 위에서 4번째줄 문장 삭제(고O광 님 제보)

그리고 모델의 데이터를 리다이렉션에도 유지시킬 수 있는 방법에 대해서도 살펴보자.

->

그리고 모델의 데이터를 리다이렉션에도 유지시킬 수 있는 방법에 대해서도 살펴보자.

254쪽 코드 7.7 제목에서

코드 7.7 Part인터페이스

==>

코드 7.7 Part 인터페이스

254쪽 1행에서(고O광 님 제보)

대부분(말장난이 아니다)의 Part 인터페이스는

==>

대부분의 Part 인터페이스는

358쪽 코드 박스 5행에서 보충 설명문 삭제(고O광 님 제보)

stmt.setString(2, spitter.getPassword());  ← 파라미터 실행

==>

stmt.setString(2, spitter.getPassword()); 

442쪽 밑에서 2~3번째 줄(고O광 님 제보)

되었더라도, 로 변경부탁드립니다. EhCacheCacheManager는

==>

되었더라도 EhCacheCacheManager는

485쪽 위에서 부터 2행에서(표기 오류. 고O광 님 제보)

배관용(pluumbing) 

==>

배관용(plumbing)

496쪽 그림 15.9에서(표기 오류. 고O광 님 제보)

Hessian/Burlap

FactoryBean

==>

HttpInvokerProxy

FactoryBean

460쪽 14.1.1절 제목에서(표기 오류. 고O광 님 제보)

14.1.1 @Secure를 이용한

==>

14.1.1 @Secured를 이용한

463쪽 본문 세 번째 문단 6행에서(표기 오류. 고O광 님 제보)

스프링 시큐리티의 선 호출 미 후 호출 애너테이션

->

스프링 시큐리티의 선 호출 및 후 호출 애너테이션

464쪽 중간 샘플 코드(표기 오류. 고O광 님 제보)

@Configuration

public class MethodSecurityConfig

==>

@Configuration

@EnableGlobalMethodSecurity(prePostEnabled=true)

public class MethodSecurityConfig

316쪽 4번째 문단 1-2행에서(번역 오류. 고O광 님 제보)

UserDetailsService 구현을 Spitter로 바꿀 수 있다는 점이다.

==>

UserDetailsService를 구현 하도록 Spitter를 바꾸는 것이다.

318 3번째 행에서(표기 오류. 고O광 님 제보)

/spitters**(Ant 스타일)

==>

/spitters/**(Ant 스타일)

최종수정일자: 2016년 3월 15일

1쇄본 오탈자

51쪽, 142쪽 코드에서(원서 오류, 정O화 님 제보)

(org.junit.contrib.java.lang.system.StandardOutputStreamLog가 사라지게 되어(https://stefanbirkner.github.io/system-rules/apidocs/org/junit/contrib/java/lang/system/StandardOutputStreamLog.html), SystemOutRule().enableLog()로 대체되었습니다.) 

  @Rule

  public final StandardOutputStreamLog log = new StandardOutputStreamLog();

==>

  @Rule

  public final SystemOutRule log = new SystemOutRule().enableLog();

178쪽 코드 5.9에서(원서 오류, 석O진 님 제보)

(SpittleController controller = new SpittleController(mockRepository);가 두 번 나오는데 위의 것을 제거해야 함)

SpittleController controller = 

    new SpittleController(mockRepository);

SpittleController controller = 

    new SpittleController(mockRepository);

MockMvc mockMvc = standaloneSetup(controller) 

==>

SpittleController controller = 

    new SpittleController(mockRepository);

MockMvc mockMvc = standaloneSetup(controller) 

179쪽 코드 5.10에서 설명 위치 수정(석O진 님 제보)

          Long.MAX_VALUE, 20));   <==  뷰 이름 반환

  return "spittles";

==>

          Long.MAX_VALUE, 20)); 

  return "spittles";   <==  뷰 이름 반환