Whiteship's Note


[GAE 시리즈] 2. 구글 로그인

모하니?/Coding : 2010.08.03 06:22


http://code.google.com/intl/ko-KR/appengine/docs/java/gettingstarted/usingusers.html

        UserService userService = UserServiceFactory.getUserService();
        User user = userService.getCurrentUser();
        if(user != null) {
            resp.setContentType("text/plain");
            resp.getWriter().println("Hello, " + user.getNickname());
        } else {
            resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
        }

이 코드가 핵심인데.. 많은 것들을 해준다.

1. 우선 무척이나 간단하다. 이렇게 쉽게 구글 로그인을 연동할 수 있다니... API도 직관적이라 어떤 일을 하는지 쉽게 알 수 있다. 마지막 줄의 코드가 로그인 한 다음 바로 로그인을 요청한 페이지로 이동하기 위한 API 인데 흠.. 괜찮은 것 같다. 권한 관리는 어떻게 하는지..  실제론 스프링 시큐리티랑 연동해서 쓰는지 아님 구글에서 제공하는 인증/권한 관리 API가 있는 것인지.. 있다면 권한 관리 설정은 편리한지 궁금하다.

2. 로그인 화면 자동생성. 로그인이 필요할 때 guestbook 예제에서 봤던 로그인 화면이 등장하는데 나는 그런 JSP 파일을 만든적도 없는데 알아서 만들어줬다. 편리하다.

3. 간편할 뿐 아니라 이 코드는 개발 환경과 배포 환경에 따라 동작 방식이 바뀐다. 오.. 놀라워라; 즉 개발환경에서는 아무런 아이디만 넣어도 로그인이 되고, 관리로 로그인하기 체크 박스가 존재한다. 하지만 GAE에 배포하는 순간 실제 구글 계정으로 로그인 한단다. 아직 GAE에 배포는 안해봤다. 그런데.. 개발할 때 실제 구글 계정으로 테스트해보고 싶으면 어쩌지?? 

4. 로그아웃 URL로 제공한다. userService.createLogoutURL()을 사용하면 된다.


top

TAG GAE, Java

[GAE 시리즈] 1. 구글 앱 엔진 + 메이븐 + IntelliJ 프로젝트 세팅

모하니?/Coding : 2010.08.03 05:21


구글 앱 엔진 시작하기 메뉴얼을 보며 예제를 실습해봤다. 그러나.. 내 입맛에 맞지 않는 구석이 몇개 있었다.

1. 라이브러리를 맘대로 추가할 수 있으니 코딩하는데는 문제가 안되는데 빌드가 보통 앤트를 사용하는 듯하다. 이건 불편하다. 그래서 메이븐을 썼다. GAE가 원하는 프로젝트 구조를 건드리지 않으면서도 필요한 라이브러리는 쉽게 가져다 쓸 수 있도록 메이븐을 설정했다. 이전에도 계속 써오던 형태라 대충 복사해서 붙여넣기고 당장 필요없는 라이브러리는 뺐다. (사실 스프링은 남겨뒀다;;)

2. 이클립스 종속적인 가이드였다. 인텔리J도 GAE 플러긴이 있으며 업데이트 사이트를 추가하는 귀찮은 작업 없이도 간편하게 플러그인을 찾아서 설치할 수 있었다.

3. 배포 설정

웹 서버에 배포할 때 프로젝트 이름/out 폴더 밑으로 웹 컨텐츠를 전부 복사해서 배포하게 되어 있는데 난 프로젝트/web에 배포하게 설정했다. 이래야 재배포 하지 않고도 JSP를 수정할 때 마다 바로바로 적용된다. 


top

TAG GAE, IntelliJ, Java

EJ2E Item 23. 새로 작성하는 코드에서는 raw type 쓰지 말자

Java : 2010.03.26 17:44


참조: Effective Java 2nd Edition. Item 23:Don't use raw types in new code

먼저 용어 정리

class List<E> {
...
}

List<String> stList = ~~~~;

이런 코드가 있을 때...
- List<E>: Generic type
- List<String>: Parameterized type
- E: Formal type parameter
- String: Actual type parameter
- List: Raw type (제목에 쓴게 이거임)
- List<?>: Unbounded wildcard type
- 나머진 패스.

Generic 장점
- 컴파일 시에 타입 안전성을 보장한다.
- 부가적인 장점으로 컬렉션에 들어있는 것을 꺼낼 때 캐스팅할 필요가 없다.

그럼 Generic을 꼭 쓰게 하지 왜 Raw Type으로 쓸 수 있게 해뒀냐?
- 호환성 때문에. 이미 1.5전 버전 기준으로 만들어 놓은 코드가 많으니까.

Generic 특성
- List<String>은 List의 하위 타입이지만 List<Object>의 하위 타입은 아니다.
- 다음 item에서 더 자세히 설명 나옴.


Raw Type을 사용했을 때 발생할 수 있는 문제

    public static void main(String[] args) {
        List<String> strings = new ArrayList<String>();
        unsafeAdd(strings, new Integer(42));
        String s = strings.get(0); // Compiler-generated cast
    }

    private static void unsafeAdd(List list, Object o) {
        list.add(o);
    }

굵은 글씨에서 타입을 명시하지 않았기 때문에
list.add(o); 여기서 일단 컴파일 경고가 발생하지만 일단 무시하고 실행할 수는 있다 막상 실행하면 ClassCastException 발생한다. 하지만 만약 저기서 List<String>이라고 타입을 명시했다면 애초에 컴파일도 못했을 것이다.

어떤 종류가 들어있는지 모르는 컬렉션을 처리하는 메서드에서는 unbounded wildcard type을 사용하자.
   
    //위험
    static int numElementsInCommon(Set s1, Set s2) {
        int result = 0;
        for (Object o1 : s1)
            if (s2.contains(o1))
                result++;
        return result;
    }

    //안전
    static int numElementsInCommon(Set<?> s1, Set<?> s2) {
        int result = 0;
        for (Object o1 : s1)
            if (s2.contains(o1))
                result++;
        return result;
    }

위에껀 왜 위험하고 아래껀 왜 안전할까? 안전한 녀석에는 무언가 추가할 수가 없다. 위험한 녀석에는 아무 객체나 넣을 수 있지만 unbounded wildcard type을 사용한 경우에는 컬렉션에 아무것도 추가할 수 없다. 컴파일 에러다.

왜? Actual type parameter가 뭔지 모르는데 뭘 집어 넣을 수 있을까.. 생각해보면 당연하다.

Type parameter를 사용할 수 없는 경우
- List<String>.class
- instanceof


top

TAG Generic, Java

[ClassLoader] Thread의 getContextClassLoader()

Java : 2010.03.11 17:57


pdf: http://www.theserverside.com/tt/articles/content/dm_classForname/DynLoad.pdf

먼저 간단한 퀴즈로 시작하는.. 긴 문서..


이 코드가 문제를 일으킬 수 있는 상황은 저 클래스를 자바 Extentions 폴더 (<JDK>/jre/lib/ext 또는 <JRE>/lib/ext)에 놓았을 경우입니다. 그렇지 않고 그냥 CLASSPATH에 둘었다면 별 문제가 없을 가능성이 큽니다. 대체 저런식으로 동적으로 로딩하려는 클래스들이 App CL의 CLASSLOADER에 있기 마련일 테니까요.

하지만, Extention 폴더로 이동하면 무슨일이 벌어질까요. ClassNotFoundExcepion이 발생합니다. 그 원인을 정확히 모르신다면 ClassLoader에 대한 아주 기본적인 개념이 부족한거라 봐도 무방하겠습니다.

이 글에서 그에 대한 해결책 두 개를 제공해주며, 그 중 하나가 바로 쓰레드 컨텍스트 클래스로더를 사용하는 것입니다.

http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#getContextClassLoader%28%29

Returns the context ClassLoader for this Thread. The context ClassLoader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. If not set, the default is the ClassLoader context of the parent Thread. The context ClassLoader of the primordial thread is typically set to the class loader used to load the application.

First, if there is a security manager, and the caller's class loader is not null and the caller's class loader is not the same as or an ancestor of the context class loader for the thread whose context class loader is being requested, then the security manager's checkPermission method is called with a RuntimePermission("getClassLoader") permission to see if it's ok to get the context ClassLoader.

별짓을 하지 않는다면 쓰레드 컨텍스트 클래스로더는 System(또는 Application) CL이 됩니다. 따라서 저 위의 코드를 자바 extentions 폴더에 넣고 실행하더라도 쓰레드 컨텍스트 클래스로더를 가져와서 loadClass를 호출하면 아무런 문제없이 동작합니다.

안그래도 대체 Thread Context ClassLoader가 왜 생긴건지 궁금했는데 이 글을 통해서 짐작할 수 있게 됐습니다. 클래스로더 계층 구조를 만들 때, 예를 들어 톰캣의 Common CL 같은 녀석은 자기 하위의 CL인 WebAPP CL에 어떤 클래스들이 들어올지 모를겁니다. 하지만 그런 상태에서 Common CL에서 WebAPP CL에서만 로딩할 수 있는 어떤 클래스를 로딩할 필요가 있다면... WebAPP CL을 직접 참조하지 않고 바로 Thread Context ClassLoader를 사용해서 로딩하도록 코딩을 하면 로딩할 수 있게 되는거죠.

흠.. 하지만 이.. 미적지근한 느낌은 뭘까요.. 왠지 상위 CL에서 하위 CL의 클래스패스에 있는걸 로딩해버리면 왠지 꼬여버릴 것만 같은 이 기분... 아.. 불안해. 왜 그럴까나..
top


[ClassLoader 퀴즈 5] Whiteship은 언제 로딩 될까?

Java : 2010.02.22 15:07


public class SpringSprout {

    Whiteship2 whiteship;

    public void makeWhiteship(){
        whiteship = new Whiteship2();
    }
}

이런 클래스가 있을 때 SpringSprout가 참조하는 Whiteship2는 과연 언제 클래스로더에 의해 로딩이 될까요? SpringSprout를 로딩할 때? SpringSprout 객체를 생성할 때? Whiteship2 인스턴스를 생성할 때. 이 중 하나가 아닐까요?

   @Test
    public void whenDoseTheDependeciesWillBeLoaded() throws Exception {
        FileUrlClassLoader fUCL1 = new FileUrlClassLoader(WIN_TEMP_CLASSPATH);
        Class springSproutClass1 = fUCL1.loadClass(TEMP_SPRING_SPROUT);
        Object springSprout1 = springSproutClass1.newInstance();

        assertThat(fUCL1.isLoadedClass(TEMP_WHITESHIP), is(B1));

        Object whiteship1 = springSproutClass1.getMethod("makeWhiteship").invoke(springSprout1, null);

        assertThat(fUCL1.isLoadedClass(TEMP_WHITESHIP), is(B2));

        System.out.println(fUCL1.loadClass(TEMP_WHITESHIP).getClassLoader());
        System.out.println(fUCL1.loadClass(TEMP_SPRING_SPROUT).getClassLoader());
    }

그래서 위와 같은 테스트를 만들어봤습니다.
이 테스트가 통과하려면 B1과 B2에는 각각 어떤 값이 들어가야 할까요?

기타 조건은 이전 글과 동일합니다.
top


[ClassLoader 퀴즈 1] Whiteship은 대체 누가 데려온 것일까?

Java : 2010.02.19 14:48


어제 면접 볼 때 받은 질문이기도 하다. 지금 내가 있는 회사에 어떻게 들어가게 됐으며 누가 데려갔고 그 사람을 어떻게 알게 됐느냐는 질문을 받았었다. 당시 난 클래스로더가 떠올랐다. 대체 누가 날 로딩한 걸까. 사부? Toby? 그 둘은 같은 사람일까?

    @Test
    public void appClassLoader() throws Exception {
        URL url = new URL("file:C:/intellij9-workspace/springsprout2/test/sandbox/classloader");
        URLClassLoader uCL1 = new URLClassLoader(new URL[]{url});
        Class whiteshipClass1 = uCL1.loadClass("sandbox.classloader.Whiteship");
       
        URLClassLoader uCL2 = new URLClassLoader(new URL[]{url});
        Class whiteshipClass2 = uCL2.loadClass("sandbox.classloader.Whiteship");
       
        System.out.println("URLClassLoader1: " + uCL1); // C1
        System.out.println("URLClassLoader2: " + uCL2); // C2
        System.out.println("whiteshipClass1 loaded by: " + whiteshipClass1.getClassLoader()); // C3
        System.out.println("whiteshipClass2 loaded by: " + whiteshipClass2.getClassLoader()); // C4
    }

편의상 콘솔에 찍히는 객체 레퍼런스를 C1, C2, C3, C4라고 표기하겠다.
test 이하의 폴더는 현재 클래스패스로 잡혀있는 상태이다.

다음 중 참인 것은?
1. C1과 C3은 같다.
2. C2와 C4는 같다.
3. C1과 C3, C4가 같다.
4. C2와 C3, C4가 같다.
5. C3과 C4는 같다.

정답은 다음 글에서 공개. To be continued!


top


[Java] ClassLoader API

Java : 2010.02.17 18:36


http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html

클래스를 로딩하는 책임을 지니고 있는 추상 클래스. 

기본전략: 바이너리 이름(String)을 받아서 파일 이름으로 바꾸고 파일 시스템에서 해당하는 이름의 클래스 파일을 읽어들인다.

위임 모델(delegation model)을 사용하여 클래스와 리소스를 찾는다. 각각의 ClassLoader 인스턴스는 연관된 상위(parent) 클래스 로더를 가지고 있다. 자신이 찾아 보기전에 상위 클래스 로더에 요청하여 먼저 찾아본다. VM 내장 클래스 로더인 "부트스트랩 클래스 로더"는 상위 클래스 로더가 없고 자신이 다른 ClassLoader 인스턴스의 상위가 된다.

보통 JVM은 플랫폼-독립적인 방식으로 로컬 파일 시스템에서 클래스를 읽어들인다. 예를 들어 유닉스 시스템에서 VM은 CLASSPATH 환경 변수에 정의되어 있는 디렉토리에서 클래스를 로딩한다.

하지만 어떤 클래스들은 파일에서 읽어오지 않고 네트워크에서 가져오거나 애플리케이션이 동작하면서 만들어지는 것도 있다. defineClass 메서드는 바이트 배열을 Class 클래스 인스턴스로 변환한다. Class.newInstance를 사용하여 그렇게 새로 정의된 클래스 인스턴스를 만들 수 있다.

클래스로더에 의해 만들어지는 객체의 메소드와 생성자는 다른 클래스를 참조할 수도 있다. 그렇게 참조하는 클래스들을 판단하기 위해 VM은 원래 클래스를 생성한 클래스 로더의 loadClass 메서드를 호출한다.

예를 들어 네트워크 클래스 로더를 만들어 다른 서버에서 클래스 파일을 다운로드 할 수도 있다. 다음은 예제 코드다.

ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();

네트워크 클래스 로더는 반드시 findClass와 네트워크에서 클래스를 읽어올 loadClassData를 정의해야한다. 바이트코드를 다운로드 한다음 defineClass를 사용하여 class 인스턴스를 만들어야 한다. 다음은 예제 구현체다.

     class NetworkClassLoader extends ClassLoader {
         String host;
         int port;

         public Class findClass(String name) {
             byte[] b = loadClassData(name);
             return defineClass(name, b, 0, b.length);
         }

         private byte[] loadClassData(String name) {
             // load the class data from the connection
              . . .
         }
     }
 

바이너리 이름

클래스로더에 전달되는 문자열로 표현한 클래스 이름은 다음에 정의된 자바 언어 표준을 따라야 한다.

예)
   "java.lang.String"
   "javax.swing.JSpinner$DefaultEditor"
   "java.security.KeyStore$Builder$FileBuilder$1"
   "java.net.URLClassLoader$3$1"

defineClass

- protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError

바이트를 Class 클래스의 인스턴스로 변환한다. Class는 resolve를 한 다음에 사용해야 한다. 

loadClass

- public Class<?> loadClass(String name) throws ClassNotFountException

loadClass(naem, false); 호출

- public Class<?> loadClass(String name, boolean resolve) throws ClassNotFountException

기본 동작은 다음과 같다.
1. findLoadedClass(String)을 호출하여 클래스가 이미 로딩되었는지 확인한다.
2. 상위 클래스 로더의 loadClass 메서드를 호출한다. 만약 상위 클래스 로더가 null이면 VM 내장 클래스 로더를 사용한다.
3. findClass(String) 메서드를 사용하여 클래스를 찾는다.

만약에 위 과정을 통해 클래스를 찾은 뒤에 resolve 플래그가 true면 반환받은 Class 객체를 사용하여resolveClass(Class) 메서드를 호출한다.

클래스로더의 하위 클래스들은 이 메서드가 아니라 findClass(String)을 재정의 할 것을 권한다.
(이런걸 지켜야 리스코프 원칙을 지켰다고 하던가...)

findLoadedClass

- protected final Class<?> findLoadedClass(String name)

만약 이 클래스로더가 JVM에 initiating 로더로 기록되어 있다면 name에 해당하는 클래스를 반환한다. 그렇지 않으면 null을 반환한다.

findClass

- protected Class<?> findClass(String name) throws ClassNotFoundException

기본 구현체는 ClassNotFoundException을 던진다. 따라서 클래스 로더를 확장하는 클래스가 이것을 구현하여 delegation 모델을 따르는 구현체를 만드는데 사용해야 한다. loadClass 메서드에서 상위 클래스 로더를 확인 한 뒤에 호출된다.
(그냥 클래스만 찾으면 되지 꼭 delegation 모델을 따라야 하는건가... 사실 loadClass가 public이라 그것도 재정의하면 그만인것을. 강요하려면 하고 말려면 말지 어중간한거 아닌가..)

resolveClass

- protected final void resolveClass(Class<?> c)

해당 클래스를 링크한다. 이 메서드는 클래스 로더가 클래스를 링크할 때 사용된다. 만약 클래스 c가 이미 링크되어 있다면 이 메서드는 그냥 끝난다. 그렇지 않은 경우라면 자바 언어 스팩의 "Execution" 챕터에 기술되어 있는대로 클래스를 링크한다.

링크


링크하기(Linking)란 클래스 또는 인터페이스 타입의 바이너리를 가져와서 JVM의 런타임에 연결하여 실행 할 수 있는 상태로 만드는 것이다. 

링크 과정은 세 가지 세부 활동으로 구성된다: verification, preparation, resolution

링크 활동 구현내용은 달라질 수 있다. 예를 들어 클래스가 사용되는 순간에 개별적으로 클래스나 인터페이스에 있는 심볼릭 레퍼런스를 확정하거나(lazy or late resolution), 검증하고나서 바로 확정할 수도 있다.(static). 즉 어떤 구현체에서는 클래스나 인터페이스를 초기화 한 이후에도 확정(resolution) 프로세스가 계속 될 수 있다는 것이다.

Verification, Preparation, Resolution


Verification: 클래스나 인터페이스의 바이너리가 구조적으로 올바른지 확인한다. 검증에 실패하면 LinkageError의 하위 클래스 중 하나인 VerifyError가 발생한다.

Preparation: 클래스나 인터페이스의 static 필드를 만들고 그런 필드들을 기본 값으로 초기화 하는 과정이 포함된다. 이 과정 중에 JVM 코드를 실행할 필요가 없다. 명시적인 static 필드 initializer는 이 과정이 아니라 initialization 과정에서 실행된다.

Resolution: 심볼릭 레퍼런스는 resolution단계를 지나야지 사용될 수 있다. 심볼릭 레퍼런스가 유효하고 반복적으로 사용되면 다이렉트 레퍼런스로 교체되어 보다 효율적으로 처리된다.

만약 이 단계를 지나다가 IncompatibleClassChangeError를 포함한 이 하위 에러들이 발생할 수 있다. IllegalAccessErrorInstantiationError, NoSuchFieldError, NoSuchMethodError

추가적으로 구현체를 찾을 수 없는 native 메서드를 선언한 클래스에서는 UnsatisfiedLinkError가 발생할 수 있다. 

하악 하악.. 오늘은 여기까지.
top


Eclipse에서 assert 문 수행 옵션 켜기

Good Tools : 2008.09.01 16:05


사용자 삽입 이미지

-ea 를 java 인자로 추가해 줍니다. -da는 끄는겁니다. 이클립스에서 기본으로 자바 클래스를 실행할 때는 assert 문을 무시하더군요. 켜주는게 좋겠죠?


top

TAG assert, da, EA, Eclipse, Java

자바의 레퍼런스 클래스 사용 가이드라인

Java : 2008.05.12 00:25


참조: http://www.ibm.com/developerworks/java/library/j-refs/

SoftReference, WeakReference, PhantomReference 클래스들이 Java2에 추가되기 전에는 오직 Strong Reference만 사용할 수 있었다.

Object obj = new Object();

여기서 obj는 힙에 저장되어 있는 개체를 참조한다. obj 레퍼런스가 존재하는한 가비지 컬렉터Garbage Collector는 저장소를 비우지 않을 것이다.

obj가 스코프를 벗어나거나 null이 될 때야 비로소 해당 객체를 참조하는 레퍼런스가 없다는 가정하에 gc의 대상이 된다. 하지만, gc의 대상이 된다고 해서 무조건 자원을 반납하는게 아니라는 것이다. 왜냐면, gc 알고리즘이 매우 다양하고 그 중에 몇몇 알고리즘은 나이 많고, 오래 산 객체들을 짧게 산 객체들 보다 덜 검사하는 경향이 있다.  따라서 gc에 의해 가용한 객체가 절대로 반환되지 않을 수도 있다. 만약에 gc가 객체 자원을 반납하는 것보다 먼저 프로그램이 종료를 하면 문제가 발생할 수 있다. 따라서, 기본적으로 gc의 대상이 된다고 해서 자원을 반드시 반납한다는 것을 절대로 보장할 수 없다.

이 정보는 레퍼런스 클래스를 분석할 때 중요하다. 비록 특정 문제에서 유용한 클래스들이기는 하지만, gc의 기본 특징 때문에 여러분이 생각하는 것 만큼 유용하지는 않을 것이다. Soft, Weak 그리고 Phantom 레퍼런스 객체들은 gc를 막지 않고 힙 객체를 참조하는 세 가지 방법을 제공한다.
  • Strongly reachable: strong reference로 참조할 수 있는 객체
  • Softly reachable: Strongly reachable 하진 않지만, soft reference로 참조할 수 있는 객체
  • Weakly reachable: 생략.
  • Phantomly reachable: 생략.
  • Clear: 객체의 레퍼런스 필드를 null로 설정한다. and declaring the object in the heap that the reference class referred to as finalizable.
SoftReference 클래스

메모리를 지각하는Memory-sensitive 캐시에 대한 레퍼런스로 사용하는 클래스이다. JVM이 out-of-memory를 발생하기 직전에 비워버리는 레퍼런스로 객체를 참조한다. 중요한 건 gc가 동작할 때, Softly reachable한 객체는 자원을 해제 할 수도 있고 그렇지 않을 수도 있다는 것이다. 객체 자원 해제는 gc 알고리즘과 gc 가 작업을 하는 시점에 가용한 메모리 양과 관계가 있다.

WeakReference 클래스

WeakReference 클래스는 기본적인 맵핑canonicalized mappings에 대한 레퍼런스로 사용하는 클래스이다. 오래 살 필요가 없고 다시 생성하는 비용이 비싸지 않는 객체에 대한 레퍼런스로 유용하다. 중요한 것은 gc 가 발동하면, Weakly Reachable한 객체의 자원을 반납한다는 것이다. 하지만, weakly reachable 한 객체를 찾고 자원을 반납하기 까지는 gc가 몇 번 발동해야 할 것이다.

PhantomReference 클래스

PhantomReference 클래스는 수집 되기 직전에 어떤 일을 수행하고 싶을 때 사용한다. ReferenceQueue와 함께 사용해야 한다.

...나머지 생략...
- 위의 세 가지 레퍼런스가 소멸 되는 과정
- 위의 레퍼런스 클래스의 get()과 ReferenceQueue의 poll()을 사용한 gc 테스트
- Weak 레퍼런스 만들려면 기본 Strong References는 null로 설정해야 함
- Soft, Weak, Phantom 레퍼런스를 다시 생성하는 방법.(gc가 발동할 수 있다는 가정 하게 코딩 해야 함.)



top