열심히 사느라 블로그는 잠시 뒷전이었습니다.
제 첫 블로그를 잠정적으로 운영을 중지합니다.
돌이켜보면 블로그에 글을 쓰고, 생각을 공유하는 시간들이 저를 만들어가는 가장 큰 원동력 중 하나였습니다.
참 행복한 시간들이었네요..
블로그를 중단 한다고 해서, 관심사가 바뀌거나 게을러 졌다기 보다는
현장에서 답을 찾기 위해 치열하게 사는데 더 집중하고 싶다고 보는게 좋을 것 같습니다.
그리고 나서 잠시 여유를 찾으면 v2로 다시 이어갈 생각입니다.
제가 궁금(?)하시거나 연락을 하고 싶으신 분은 메일이나 얼마전에 시작한 페이스북으로 오세요^^.
물론, 생각보다 일찍 다시 블로그 v2를 시작할지도 모르겠습니다. (벌써부터?)
사실 블로그가 중요한게 아니고 지금 제 생각을 어떻게 정리하고, 또한 이를 어떻게 공유할 것인지의 방법적인 측면을 고민해봐야겠죠.
아무튼 그 동안 부족한 제 블로그를 구독해주시고, 많은 관심을 가져주셔서 감사드립니다.
새로운 공간을 마련하면 다시 한 번 글을 남기겠습니다.
그럼 즐거운 주말 되세요.
일곱 번째 강의 입니다.
이제는 폴리텍 대학 홈페이지를 통해서만 접수 받습니다.
홈페이지에 방문하셔서 서류 작성 후 팩스로 보내면 바로 접수 됩니다.
자세한 내용은 폴리텍 대학 담당자 번호인 02-6300-6300 로 연락하시면 됩니다.
[접수하러 가기]
그럼 즐거운 하루 되세요.
이번 달 마소에는 특집 기사로 Spring 3.0에 대한 내용이 실렸습니다.
제가 그 중에 '스프링 프레임워크 3.0을 이용한 RESTful 웹서비스 구현' 글을 작성했는데 글 내용 중 오류가 있어 내용을 정정해 올맀습니다.
다음 달 호에 정정문이 실리겠지만 이번 달 마소를 읽으시고 혹시나 혼란스러워할 분이 계실 것 같아 미리 블로그에 공지합니다.
그럼 아래 내용을 참고해주세요.
마소 담당자분과 이 글을 읽고 혼란스러워 하신 독자 분들께 죄송한 말씀 올립니다 (_ _).
<정정 내용>
<리스트 5>에서 설명하는 인터페이스를 MessageConverter에서 HttpMessageConverter로 정정합니다. 그 외 관련 본문 내용의 'MessageConverter'도 'HttpMessageConverter'를 의미하므로 참고해주시기 바랍니다.
<리스트 5 정정 코드>
package org.springframework.http.converter;
public interface HttpMessageConverter<T> {
// 메시지 컨버터의 읽기 지원 여부
boolean canRead(Class<?> clazz, MediaType mediaType);
// 메시지 컨버터의 쓰기 지원 여부
boolean canWrite(Class<?> clazz, MediaType mediaType);
// 메시지 컨버터가 지원하는 미디어 타입 목록 반환
List<MediaType> getSupportedMediaTypes();
// 요청 메시지를 clazz 인자 타입의 객체로 변환
T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
throws IOException, HttpMessageNotReadableException;
// t 객체를 메시지 컨버터가 지원하는 타입으로 변환 후 응답 스트림에 반영
void write(T t, MediaType contentType, HttpOutputMessage outputMessage)
throws IOException, HttpMessageNotWritableException;
}
벌써 6차 교육입니다.
강의에 대한 자세한 내용은 아래 링크를 참조해주시면 감사하겠습니다.
지금 예상으로는 금번 강의를 포함해서 두 번 정도의 강의를 마지막으로 할 것 같습니다.
이번 강의는 기본적인 강의 구성은 그대로 진행하지만 강의 참가자 분들과 더 다양하게 소통할 수 있는 기회를 마련해보도록 하겠습니다.
시간 별로 특정 주제에 대해 의겨을 나누는 시간이 마련할 생각입니다.
아쉽게도 5차 때는 하지 못했던 뒷풀이(?)도 반드시 할 생각입니다.
아무쪼록 금번 강의도 즐거운 6주가 됐으면 좋겠습니다.
감사합니다.
Spring IDE를 설치하면 기본적으로 제공하는 뷰 중에 하나로 'Spring Explorer'가 있습니다.
하지만 일반적으로는 잘 사용하지 않습니다. 정확히 말하자면 개발 중에 그렇게 볼 필요가 없다는 겁니다.
그러나 빈 설정을 애노테이션으로 하기 시작하면서 얘기가 조금 달라졌습니다.
빈 설정을 애노테이션으로 하거나, Autowiring을 위주로 사용하보니 명시적으로 의존성을 관리할 때에 비해서 직접 테스트나 시스템을 띄우기 전까지는 의존성 관계가 정상적으로 되었는지 확인하기가 어렵다는 겁니다. 어떨때는 시스템을 띄워서 에러 메세지를 보고도 바로 파악하지 못하고 해매는 경우도 발생합니다.
방금 전 강의에서도 한 분이 패키지가 다른 위치에 있는 빈인지 모르고 특정 빈(컨트롤러)가 왜 매핑이 안되는지 한참을 찾는 경우가 발생했습니다. 의존성 주입인 경우에는 그나마 나은데 이번에는 컨트롤러다 보니 의존성 주입 실패가 아니라 웹 요청이 매핑되는 핸들러가 없다고 하니 이 부분ㅇ르 바로 캐치하지 못하신 거였죠. 더군다나 빈의 갯수가 많아지면 더 힘들겠죠.
이럴 때 Spring Explorer를 활용해 실제로 시스템이 올라갈 때 등록되는 빈들을 미리 확인할 수가 있습니다. 위의 분의 경우에도 Spring Explorer을 보고 나서 바로 빈이 올라가지 않아서 그렇다는 상황을 바로 알아낼 수가 있었습니다.
상황을 공유하려고 간략히 쓰려고 했는데 조금 길어졌군요..;
Prev
Rss Feed