개발은 꽃

서블릿 리스너와 필터 서블릿 리스너 서블릿 컨테이너에서 발생하는 주요 이벤트를 감지하고 각 이벤트에 특별한 작업이 필요한 경우에 사용한다. 서블릿 컨텍스트 수준의 이벤트 컨텍스트 라이프사이클 이벤트 컨테스트 라이프사이클 이벤트의 리스너를 만들어보자 리스너 public class MyListener implements ServletContextListener { //리스너 초기 설정 @Override public void contextInitialized(ServletContextEvent sce) { System.out.println("Context Initialized"); sce.getServletContext().setAttribute("name", "mesung"); } @Override publ..

서블릿 애플리케이션 개발 maven 프로젝트 생성 pom.xml 간략 설명 junit junit 4.11 test javax.servlet javax.servlet-api 4.0.1 provided JUnit Scope : test 소스 classpath 에서는 사용 못하고 오롯이 테스트를 실행할 때만 사용이 가능하다. Servlet Scope : provided 이 의존성을 언제 어떻게 classpath에 넣고 쓸것이냐의 범위를 뜻한다. 코딩 시점에는 사용이 가능하나, 런타임 시점(war 패키징 시점)에는 classpath에서 제외된다. 해당 API는 어딘가(컨테이너)에서 제공이 되어진다는 뜻이다. 이로 인해서 런타임 시점에서는 classpath에서 제외되도 괜찮다는 것이다. 소스 패키지 설정 File..

서블릿 애플리케이션 서블릿 한 프로세스를 공유하는 스레드를 만들어서 요청을 처리한다. 이로인해, 빠르다는 장점을 가지고 있다. 서블릿 엔진 또는 서블릿 컨테이너 세션 관리 네트워크 서비스 MIME 기반 메시지 인코딩 디코딩 서블릿 생명주기 관리 서블릿 애플리케이션 실행 서블릿 애플리케이션은 서블릿 컨테이너가 실행할 수 있으므로, 반드시 서블릿 컨테이너를 사용해야 한다. 서블릿 컨테이너가 서블릿 애플리케이션 실행하는 방법(서블릿의 생명주기) init() : 최초 요청을 서블릿 컨테이너가 받았고, 요청을 처리할 서블릿 인스턴스의 init()을 호출하여 초기화 한다. 최초 요청을 받았을 때 한번 초기화 하고 나면 그 다음부터는 이 과정을 생략한다. 서블릿을 요청한 다음부터는 클라이언트의 요청을 처리할 수 있다..

equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서는 hashCode도 재정의해야한다. 만약, hashCode를 재정의하지 않을 시, HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. Object 명세에서 발췌한 규약을 살펴보자 Equals 비교에 사용되는 정보가 변경되지 않았다면, hashCode 메소드는 몇번을 호출해도 항상 같은 값을 반환해야 한다. 단, 애플리케이션이 다시 시작할 시에는 이 값이 달라져도 상관 없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체르 다르다고 판단했더라도, 두 객체의 hashCod..

equals는 일반 규약을 지켜 재정의하라 Equals 메소드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있어 자칫하면 끔찍한 결과를 초래할 수 있다. 이런 이유로 인해 아예 재정의 안하는 것이 옳은 선택일 수 있다. 다음 상황에 맞닥드릴 시에는 재정의를 하지 않는 것이 좋다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스를 말한다. 인스턴스의 논리적 동일성을 검사할 일이 없다. 인스턴스의 논리적 동일성을 검사할 일이 없다면 Object의 기본 equals만으로 해결이 된다. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. Set구현체는 AbstractSet이 구현한 equals를 상속받아 사용하고, List 구현체들은 Abst..

명명 패턴보다 어노테이션을 사용하라 테스트 프레임워크인 JUnit은 버전 3까지 테스트 메서드 이름을 test로 시작하게끔 했다. 하지만 이런 명명패턴은 단점이 존재했다. 명명패턴의 단점 오타가 나면 안된다. 실수로 tsetSafetyOverride로 지으면 JUnit 3은 이 메소드를 무시하고 지나치기 때문에 해당 테스트가 통과했다고 오해할 수 있다. 올바른 프로그램 요소에서만 사용되리라 보증할 방법이 없다. 메서드가 아닌 클래스의 이름을 TestSafetyMechanisms으로 지어 JUnit에 던져줄 시 JUnit은 클래스의 이름에는 관심이 없어 무시해버린다. 그로 인해, 테스트를 하지 않고 지나치기 때문에 개발자는 이번에도 테스트가 통과했다고 오해할 수 있다. 프로그램 요소를 매개변수로 전달할 마..

@Override 어노테이션을 일관되게 사용하라 해당 어노테이션을 일관되게 사용하면 여러가지 악명 높은 버그들을 예방해준다. 다음 Bigram 프로그램을 살펴보자. Bigram은 영어 알파벳 2개로 구성된 문자열을 표현하는 소스다. pubcli class Bigram { private final char first; private final char second; public Bigram(char firtst, char second) { this.first = first; this.second = second; } public boolean equals(Bigram b) { return b.first == first && b.second = second; } public int hashCode() { r..

검사 예외와 런타임 예외 자바는 문제 상황을 알리는 타입(Throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다. 하지만, 해당 타입을 언제 무엇을 사용해야하는 지 헷갈리는 경우가 있다. 그럼 이것들은 언제 무엇을 사용해야 하는가? 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용해라 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서, 메소드 선언에 포함된 검사 예외 각각은 그 메소드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다. Ex. API 메소드 호출 시 강제적으로 try-catch 혹은 throw 를 해야하는 경우 비검사 throwable은 두 가지로, 런타..