자바 1.5에서부터 제너릭 기능이 추가 되었다. 내가 아는 제너릭은 타입 캐스팅의 비용을 줄이고, 런타임시에 발생하는 오류를 줄이며, 가독성이 좋은 코드를 만들기 위해 나온 기술이라고 알고 있다.또 한 가지 제너릭을 통해 메소드의 return 타입의 제약을 해소하고, 타이트하게 문법을 체크하는 정적 타입 언어의 특성에서 동적 타입 언어와 같은 느슨한 스타일의 언어로 변화되기를 원하는 것 같다. 정적 타입 언어는 IDE툴을 이용하여 컴파일 타임에 문법 체크 및 오류를 사전에 발견할 수 있는 장점이 있다. 그러나 문법의 타이트한 체크로 인해 코드양이 많아진다.이런 단점을 자바에서는 제너릭을 이용해 해소하고 있다. 동적 언어는 런타임 시에만 문법 오류를 확인할 수 있고, 강력한 개발 도구도 많지 않다.또한 동..
스프링을 공부하다 보면 빈, 빈 팩토리, 애플리케이션 컨텍스트, 스프링 컨테이너, IoC 컨테이너 등 다양한 용어들이 나온다. 궁극적으로 이 용어들이 가리키는 것은 스프링 설정 xml 파일을 말한다.단순하게 스프링 xml 설정 파일을 가리키는 것 뿐이라면 왜 이렇게 많은 용어들이 탄생했고, 또 사용되어져 있는지 궁금하지 않을 수 없다. 솔직히 난 불편하다. (아주 쬐금~)가정 먼저 개발자들간의 커뮤니케이션 시 위에서 언급한 용어들을 무분별하게 사용하다보니 혼란스럽다.또한 애플리케이션 컨텍스트의 용어는 흔히 tomcat server.xml에 정의한 context를 말하는 것 같다. 물론 용어들을 세분화하면 각 용어들이 뜻하는 바를 정확하게 설명할 수 있겠지만 조금은 불편하게 사실이다. 여하튼 내 불만에 대..
내가 블로그를 쓰는 이유? 새롭게 배운 지식과 경험 그리고 생각들을 이곳에 작성함으로써 시간이 흘러 까먹더라도 이곳에 들어와 글을 읽으며 저 깊숙한 곳에 있는 기억과 지식들을 끄집어 내기 위해서이다. 다른 한 가지 이유는 어떤 한 가지 사건과 경험 그리고 배움들을 구체화된 글로 작성함으로써 나의 생각을 정리하고, 이를 통해서 다른 사람들에게 보다 잘 설명할 수 있는 기틀을 만들어 나가기 위해서이다. 마지막으로 내 꿈을 실현할 수 있는 한 가지 도구로써의 가치가 있기 때문이다.지식을 얻고, 그것을 글로 표현하며 정리하고, 이를 토대로 사람들에게 더 좋은 정보를 알려줄 수 있는 것.그것이 내 꿈을 향해 나아갈 수 있게 해주는 하나의 도구로써 가치가 있는 것이다. 2년 넘게 일기를 쓰는 습관을 들여서 그런 건..
오픈 소스를 사용하다보면 특정 클래스가 어떤 방법으로 코드가 구현되어 있는지 궁금할 때가 있다. 난 이클립스에 jad를 추가하여 decompile된 class파일을 보았는데 코드가 깔끔하게 나오지 않아서 불편했다. 또 다른 방법은 프로젝트 Java build path > Libraries에서 jar attached source를 하여 다운로드 받은 소스를 연결하는 방식이 있다.헌데 이 방법은 완전 노가다이다.한번만 노가다를 하면 괜찮지만 새로운 프로젝트를 생성하면 동일한 노가다를 또 해야 한다. 메이븐은 소스 다운로드 및 jar attached source를 자동으로 해준다는 것을 최근에 알게 되었다. 멋지다. ^^이런 좋은 기능이 있다는 걸 이제서야 알다니. 소스 다운로드 방법은 goal 에 다음을 추..
관계형 테이터베이스 테이블과 객체 사이의 mapping 처리를 해주는 것을 ORM(Object relational Mapping)이라고 한다. 쉽게 말해 SQL문 작성 없이 간단한 매핑 설정으로 데이터베이스의 테이블 데이터를 Java 객체로 전달 받을 수 있는 것이다. ORM을 이용하면 개발을 좀 더 편하게 할 수 있고, service layer에 집중할 수 있다. ORM을 사용하고 있는 JPA, 하이버네이트 예제 코드를 보면 상당히 편리하고 다양한 기능을 제공하고 있는데 이 기술을 사용하려면 학습 비용이 다른 오픈 소스보다 높다고 생각된다. 각 프로젝트 규모나 성격에 맞게 ORM, SQL Mapper 둘 중 하나를 선택하면 되겠지만 현재 우리 프로젝트 환경에는 iBatis가 적절한 것 같다.
현재 프로젝트에서는 commons dbcp pool과 tomcat jdbc pool을 사용하고 있다. 몇일 전에 스터디 그룹에서 나왔던 얘기가 apache commons dbcp는 하드웨어 멀티 코어를 제대로 활용하지 못해서 성능이 떨어지고, 소스 버전 업데이트는 거의 이뤄지지 않는다고 한다.몇 가지 더 알아보니 commons dbcp는 하나의 쓰레드를 사용하기 때문에 멀티쓰레드 안전성을 보장하고자 전체 connection pool에 대한 lock을 건다고 한다. dbcp의 단점에 비해서 tomcat jdbc pool은 하드웨어의 멀티 코어를 충분히 활용하고 성능이 좋다고 한다.성능이 좋다는 기준이 dbcp보다 좋은 건지 다른 컨넥션 풀링보다 좋다는 건지는 모르겠지만 어느 정도의 안전성을 보장한다는 의미..
maven의 의존 라이브러리(jar) 파일들을 다운로드 받으면 내 로컬 PC의 C:\Users\namkyu\.m2\repository 디렉토리에 저장 된다.하지만 내 로컬 PC 개발 환경은 D드라이브의 dev 폴더로 집중하기 때문에 C 드라이브에 라이브러리가 저장되는 것이 싫었다. 그래서 바꿨다.일단 maven home > conf 디렉토리로 이동하여 settings.xml 파일을 open 한다. root 엘리먼트 하위에 보면 localRepository 엘리먼트가 보이는데 여기에 변경할 디렉토리 경로를 입력해 주면 된다.D:\dev\local_repository 이제는 이클립스에서 위에서 수정한 settings.xml을 지정해 주자.이클립스 > window > Preferences 클릭좌측의 tree ..
[*.do에서 /* 로 바꾸게 된 이유]스프링 3.1 샘플 프로젝트의 web.xml(DD) 구성 시 url-pattern을 *.do와 같이 설정하였다. 이유는 단순하다.프로젝트를 진행할 때 항상 *.do를 사용했기 때문이다. 하지만 REST 방식의 웹 어플리케이션을 구성하기 위해서는 다음과 같은 URL 형식을 제공해야 하는데 현재는 *.do와 같이 되어 있기 때문에 pattern을 /* 와 같이 변경해야만 했다.http://localhost:8080/user/list [현상]이제 내가 만들어 놓은 프로젝트는 REST 방식을 지원하는 spring web application이 되었다.허나 controller mapping url을 호출하면 404 에러가 발생하면서 아래와 같은 로그가 찍힌다.No mappi..
spring 기반으로 되어 잇는 웹 어플리케이션의 web.xml에 대한 정리정리의 목적은 곧 있을 스프링 3.1 교육을 위해 머리로 알고 있는 것들을 기록으로 남겨 좀더 자세하게 정보를 전달하기 위함이다. 일단 web.xml은 서블릿 배포 서술자 (DD) 라고 부른다.영어로는 Deployment Descriptor DD의 용도는 WAS 구동 시 /WEB-INF 디렉토리에 존재하는 web.xml 파일을 읽어 들여 웹 어플리케이션 설정을 구성하기 위함이다. 가령 스프링, 스트럿츠 등 다양한 프레임워크를 사용하여 웹 어플리케이션을 구성하거나 로그, 인코딩 설정 등 초기 셋팅을 위한 설정 파일이라고 생각하면 된다.결국 설정을 위한 설정 파일이라고 정리되는 것인가? ㅋ DD 파일의 title 정도라고 생각하면 좋..
콜렉션 클래스들은 저장된 객체들에 대한 순차적 접근을 제공한다.그러나, 순차적 접근이 모두 끝나기 전에 콜렉션 객체에 변경이 일어날 경우 순차적 접근이 실패되면서 ConcurrentModificationException 예외를 return하게 되는데 이를 fail-fast 방식이라고 부른다. Enumeration은 순차적 접근 시 콜렉션 객체에 변경이 일어나도 이를 무시하고, 끝까지 동작하는 반면에Iterator는 fail-fast 방식으로 동작한다. 아래는 fail-fast 동작에 대한 테스트 코드이다. 테스트 결과자바 콜렉션 프레임워크에 포함되어 있는 List, Vector, HashTable 등은 모두 fail-fast 방식으로 동작 Enumeration 인터페이스만 fail-fast 방식이 아님
@RunWith() 스프링의 테스트 컨텍스트 프레임워크 JUnit 확장 기능 지정 Junit은 각각의 테스트가 서로 영향을 주지 않고 독립적으로 실행됨을 원칙으로 하기에 @Test 마다 오브젝트를 생성한다. 이와 같은 Junit의 특성으로 인하여 ApplicationContext도 매번 새로 생성되기 때문에 테스트가 느려지는 단점이 있다. 그러나 @RunWith 애노테이션은 각각의 테스트 별로 오브젝트가 생성 되더라도 싱글톤의 ApplicationContext를 보장한다. @RunWith() 대신 AbstractJUnit4SpringContextTests를 상속받아 사용할 수 있음. @ContextConfiguration() spring bean 메타 설정 파일의 위치를 지정할 때 사용되는 애노테이션이며..
화면 입력, 수정, 상세 보기 페이지를 개발할 때 다음과 같이 두 가지 방법을 생각해 볼 수 있다. 첫 째는 insert.jsp, update.jsp, detail.jsp 세 개의 파일을 생성하여 각각의 화면 구성을 file 단위로 분리하는 것이고 둘 째는 memberInfo.jsp 와 같이 하나의 파일에 if(flag)와 같은 조건문을 추가하여 분리하는 것이다. 하지만 위의 두 가지 방법은 큰 문제가 있다. 코드의 중복이 발생하고, 당장은 개발이 편하고 고민할 거리가 없다고 생각하겠지만 이후 유지보수에 상당한 비용이 발생하게 되기 때문이다. 그럼 어떻게 하면 코드의 중복이 발생하지 않고, 유지보수의 어려움을 최소화 할 수 있을까? 나의 생각은 다음과 같다. 회원 가입 페이지 접근 시 memberInfo..
스프링 메타 애노테이션 이란? 스프링에서는 기본적으로 클래스 선언부 위에 @Component 애노테이션이 붙어 있으면 스프링 빈으로 생성한다.하지만 실무에서는 다음과 같이 한다.Controller 클래스에는 @ControllerService 클래스에는 @ServiceDAO 클래스에는 @Repository 위의 3가지 애노테이션도 스프링 빈으로 생성해주는 애노테이션들이다. 분명 위에서 설명하기를 @Component 애노테이션이 스프링 빈으로 생성해준다고 했는데 왜 위의 3가지 애노테이션도 빈으로 생성해 주는 걸까?이유는 @Component 애너테이션이 메타 에노테이션으로 달려 있기 때문이다. 이말이 무슨 말이냐하면@Target(ElementType.TYPE)@Retention(RetentionPolicy...
경제학 강의를 보고 있다. 강사의 강의 스타일이 상당히 독특하고, 재미있다. 무엇보다도 설명을 쉽게 해 이해도가 높다.허나 아무리 이해도가 높아도 시간이 지나면 다 잊어 버리는 나를 알기에 이제부터라도 그 내용을 정리하고자 한다. 오늘의 주제는 "기회비용1" 이다. 기회 비용은 총 3개로 강의가 이뤄져 있기 때문에 이후에도 2번 더 포스팅을 할 것이다. 경제학이라는 학문이 최초로 나오게 된 것은 아담 스미스가 논문으로 작성한 "국부론"이 그 시작이었다. 그 시절의 학자들은 국부론을 처음 접할 때에는 철학으로 분류를 하였지만 내용을 읽다 보니 이 책은 철학으로 분류하면 안 되겠다고 판단하여, 이를 경제학으로 분류하기 시작했다. 이것이 최초의 경제학 책이다. 아담 스미스의 국부론은 예전에도 많이 들어왔던 터..
API에 있는 HashMap 클래스의 모든 메소드에 대해서 테스트 케이스를 작성해 보았다. 나 요즘 테스트 코드 작성하는 재미에 푹 빠진 것 같다. 아래는 소스 코드 게시판인 github gist를 이용하여 코드를 보여주고 있다.
synchronized 키워드를 사용하는 전형적인 3가지 케이스에 대해서 테스트 코드를 작성해 보았다. 첫 번째는 메소드에 synchronized 키워드를 추가하여 메소드 lock을 걸어주는 방법두 번째는 synchronized(객체)와 같이 객체의 레퍼런스 변수를 이용하여 lock을 걸어주는 방법세 번째는 synchronized(this)와 같이 메소드 구현부에 자기 자신의 객체에 대한 lock을 걸어주는 방법 테스트는 Junit을 이용하여 구현하였고, Junit으로 Multithread test 코드 작성 시 Program Argument 영역에 아래 옵션을 추가해 줘야 한다. 실행할 class 선택 후 오른쪽 마우스 클릭 > Run As > Run Configurations...Argument 탭으..
junit 테스트 메소드를 여러 개 생성하였을 때 특정 메소드에서만 테스트를 진행하고 싶을 때가 있다. 그럴 때에는 메소드 명에 살포시 커서를 올려 놓은 후 ctrl + F11을 누르도록 하자. 또 다른 방법은 @Ignore 애노테이션을 이용하여 테스트를 제외시킬 수 있다.
간혹 아래와 같이 html table을 merge한 후 화면에 보여줘야 하는 경우가 있다. 전에는 for문 돌리며 if 처리를 통해 해결했는데 다음과 같이 DOM을 이용하면 코드를 이해하기 쉽고, 유지보수하기 편해진다. 다음은 샘플 코드이다. 여기서 중요한 부분은 꼭 merge할 cell은 정렬이 되어 있어야 한다는 것이다. (DB에서 query 조회 시 order by를 이용하여 정렬 처리) 정렬이 안 되어 있는 상태에서 merge를 하게 되면 다음과 같이 원하지 않는 결과를 가져올 수 있다. 이유는 코드를 확인해 보면 안다.