까먹지말자! http://kwon37xi.egloos.com 권남, 코드로 말하다. ko Fri, 11 May 2012 07:37:26 GMT Egloos 까먹지말자! http://pds11.egloos.com/logo/200810/14/15/b0046915.jpg http://kwon37xi.egloos.com 80 80 권남, 코드로 말하다. <![CDATA[ [DEBUG] IE <input type="file"> click 이벤트 발생시키기 ]]> http://kwon37xi.egloos.com/4703036 http://kwon37xi.egloos.com/4703036
비 IE 브라우저에서는 문제 없다.

또한 해당 DOM이 display: none; 혹은 visible: hidden; 상태일 때도 마찬가지이다.

File Input 에 스타일을 줄 경우 IE에서는 File Input DOM 이 투명 상태로 스타일의 위를 덮어서 직접 click 이벤트를 받도록 해야한다.

]]> 프로그래밍 http://kwon37xi.egloos.com/4703036#comments Fri, 11 May 2012 07:36:38 GMT 권남 <![CDATA[ 스프링 시큐리티 3 ]]> http://kwon37xi.egloos.com/4697743 http://kwon37xi.egloos.com/4697743
스프링 시큐리티 3 - 8점
피터 뮬라리엔 지음, 유윤선 옮김/위키북스


아마존에서는 이상하게 평가가 나쁜데 나는 매우 좋게 읽은 책이다.

우리나라에서는 사실상 구할 수 있는 유일한 Spring Security 3 에 관한 책인데다, 설명도 쉽고 차근 차근 잘 하고 있다. 번역 품질도 읽는데 부담 없는 상당히 잘 된 편에 속한다.

Spring Security는 스프링의 부가 프레임워크들 중에서 가장 어려운 축에 속하는 녀석이다.
하지만 제대로 이해하면 그 강력함이 이루 말할 수가 없다.

예전 프로젝트에서는 이 책도 없고 불친절한 Spring Security 기본 문서를 보다가 때려 치워버렸었는데, 이번에 하고 있는 프로젝트에서는 기본으로 사용하고 있는데다 이 책까지 나와서 참 좋다.

스프링 시큐리티를 아직 도입하고 있지 않다면 꼭 이 책을 읽고 도입 여부를 타진해보기 바란다. 비록 배우기가 까다롭긴 하지만 매우 만족할 만하게 보안 설정 자동화/집중화를 이룰 수 있을 것이다.
]]> http://kwon37xi.egloos.com/4697743#comments Tue, 24 Apr 2012 10:08:53 GMT 권남 <![CDATA[ [DEBUG] IE 9이하에서 textarea의 포커스가 다른 요소로 이동시, textarea의 커서위치 및 선택영역 초기화 되는 문제 ]]> http://kwon37xi.egloos.com/4693402 http://kwon37xi.egloos.com/4693402
포커스를 받는 요소들 input/button 혹은 다른 textarea 등으로 이동할 때 발생하는 버그로 보인다.

해소 방법은 포커스 이동전에 기존 커서의 위치와 선택 영역을 기억하고 있다가 포커스가 돌아오면 복구시켜주는 정도..
복구는 jCaret을 이용하면 쉽게 된다.
]]> 프로그래밍 http://kwon37xi.egloos.com/4693402#comments Tue, 10 Apr 2012 07:36:15 GMT 권남 <![CDATA[ [DEBUG] Hibernate에서 갑자기 발생하는 NullPointerException의 정체는? ]]> http://kwon37xi.egloos.com/4690734 http://kwon37xi.egloos.com/4690734

Exception in thread "main" java.lang.NullPointerException
at org.hibernate.persister.entity.AbstractEntityPersister.loadByUniqueKey(AbstractEntityPersister.java:1641)
at org.hibernate.type.EntityType.loadByUniqueKey(EntityType.java:608)
at org.hibernate.type.EntityType.resolve(EntityType.java:382)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:116)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2211)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095)
at org.hibernate.loader.Loader.list(Loader.java:2090)

NullPointerException when Query.list() 에 버그 리포팅이 된 상태이며 아직도 해결이 안되고 있다.

일단 문제는  엔티티간의 연관 관계가 있을 때 발생하는 것으로 보이나, 일관성은 없다.

우리의 경우 아래와 같이 @OneToOne에 @Id를 지정한 관계를 가진 엔티티(아래 선언에서 Something 엔티티)의 목록을 가져올 때(list()) 발생하였다.

@Id
@OneToOne
private Something somethimg;

일단은, ID를 Long형으로 하고, OneToOne은 그냥 관계로서만 두도록 하니까 문제늘 발생하지 않았다.

우리팀은 JPA 구현체로서 하이버네이트를 사용하기 때문에 해결이 안되는데 loadByUniqueKey error and many-to-many w/join table의 댓글에 따르면 아무일도 안하는 하이버네이트 필터를 만들어 끼워 넣으면 땜빵 해결이 되긴 한다고 한다.

<filter name="myFilter" condition="1=1"></filter>

<filter-def name="myFilter">
</filter-def>

currentSession.enableFilter("myFilter");


빨리 해결 되기를.
]]> 프로그래밍 http://kwon37xi.egloos.com/4690734#comments Mon, 02 Apr 2012 04:43:07 GMT 권남 <![CDATA[ [DEBUG] Eclipse + Maven 조합에서 갑자기 단위테스트가 실행이 안된다. ]]> http://kwon37xi.egloos.com/4688391 http://kwon37xi.egloos.com/4688391
갑자기 단위테스트가 안되면서 아래와 유사한 오류가 모든 단위테스트에서 발생하였다.
Class not found ClassToTest
java.lang.ClassNotFoundException: ClassToTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)


ClassNotFoundException when running JUnit unit tests within Eclipse (using Maven)를 보고 힌트를 얻어 해결하였다.

근데, 사실 난 뭔 소리인지 정확히는 모르겠고,
  1. Maven 모듈로 분리된 프로젝트에서 발생하는 버그인 듯 하며,
  2. 해당 모듈 프로젝트를 삭제(내용은 남겨둠)했다가, 다시 Existing project로 import 해주면 해결이 된다.

이거 때문에 2 뽀모도로 날렸다.

책임져... 씨...

]]> 프로그래밍 http://kwon37xi.egloos.com/4688391#comments Mon, 26 Mar 2012 05:54:25 GMT 권남 <![CDATA[ Javascript 병렬 적재 라이브러리가 정말 의미있을까? ]]> http://kwon37xi.egloos.com/4688068 http://kwon37xi.egloos.com/4688068 head.js라는 Javascript를 백그라운드에서 병렬로 로딩하여 실행해 주는 라이브러리가 있다. 그 외에도 이와 같은 일을 하는 라이브러리가 몇가지 더 있다.

여기서 역할이 두 가지임에 주의해야 한다.
1. 백그라운드에서 비동기로 Javascript 적재 - 웹페이지의 표시 시점이 빨라짐
2. 순차 적재가 아닌 병렬 적재(여러 JS를 동시에 읽어 들임) - javascript 적재가 빨라짐

(기본적으로 <script>태그를 HTML 상단 즉, <head>에다 두면 HTML 표시가 느려진다는 사실은 다들 알고 계시리라...)

이번에 우리 프로젝트에서 이 라이브러리를 도입하여 속도를 높여볼까 하다가, 실제 성능 측정을 해보고는 그만 두었다.

이유는
1. 백그라운드에서 비동기 Javascript 적재는 단순히 <script> 태그를 </body> 앞으로 옮기는 것 만으로도 동일한 효과(웹페이지 표시 시점 빠르게)가 이뤄지기 때문이다.
2. Javascript 병렬 적재는 이미 IE 8을 비롯한 메이저 브라우저가 다 기본적으로 지원해 주고 있기 때문이다.

그런데 head.js 의 성능 테스트 페이지를 보면 (head.js사용시, script아래로했을시) head.js를 사용했을 때가 압도적으로 빠르게 나오는 듯 보인다.

그러나 내가 분석한 결과 저 테스트는 잘못되었다.

저 테스트에서 로딩이 끝나는 시점을 window.onload 시점으로 잡았는데, 이는 문제가 있다.
실제로 우리가 측정해야 할 시점은 1. HTML이 표시되는 시점, 2. Javascript가 사용가능해 지는 시점 이 두가지 인데, head.js 사이트의 테스트에서는 엉뚱하게 window.onload 시점을 기준으로 잡은 것이다.

head.js 사이트의 테스트를 내가 직접 해본 결과로는 IE 9 에서는 일관성있게 head.js를 사용했을 때가 빠르게 나오지만, 파이어폭스와 크롬 브라우저에서는 대중 없이 이게 빨랐다 저게 빨랐다 한다. 내가 로컬 웹서버에 웹 페이지를 만들어 올려 놓고 해봐도 마찬가지 결과가 나왔다.

그래서 나 스스로 직접 성능 테스트를 rough 하게 해 보았는데, 결과는 거의 내 예상대로 head.js 를 사용했을 때의 이득이 없었다. 테스트는 Script를 아래로 내렸을 때(즉, </body> 바로 위에 script를 두었을 때)와 head.js를 사용했을 때로 나누어서 해보았으며 HTML 출력이 끝난 시점과 javascript가 사용가능해진 상태($(document).ready() 상태 혹은 head.ready() 상태)의 시간을 측정해 보았다(아래 결과만 보고 FF가 느리다고 하지는 마시길. 내 메인 브라우저가 FF라서 플러그인만 20개 정도가 깔려있다. 다른 브라우저는 플러그인을 하나도 안 깐 상태이다. 상대적인 값만을 보시길).
브라우저Script아래로head.js
 HTML출력끝난시점JS사용가능상태HTML출력끝난시점JS사용가능상태
Firefox 1123.3ms253.5ms40.8ms210.6ms
IE 924.5ms157.7ms19.2ms463.5ms
Chrome 178.4ms135ms15.5ms142.2ms

위 값은 모두 각 브라우저에서 10회씩 Ctrl-Shift-R 혹은 Ctrl-F5를 눌러서 페이지를 로딩해서 나온 값의 평균이다.
* IE 9는 head.js를 사용했을 때 현저한 성능 저하를 보였다.

보면 알겠지만 어떨 때는 Script아래로 했을 때가 성능이 더 좋기도 하고 어떨 때는 head.js를 사용할 때가 더 좋게 나오기도 하지만 대체로 Script를 아래로 했을 때가 성능이 더 좋다는 것을 볼 수 있다.

내 예상대로 작동한 경우는 Chrome 뿐이다. 내 상식에 따르면 Chrome 와 같은 반응을 보이는게 옳다. 뭔지는 모르지만 각 브라우저내의 독특한 javascript를 다루는 방식이 결과에 영향을 주는 것 같다.

우리팀의 목표는 HTML 출력 시점을 앞당기는 것이므로, <script>를 아래로 두는 것이 더 적합하고, 이는 아마도 대부분의 일반적인 웹사이트들도 마찬가지 일 것이다.

아무튼 이렇게 하여 내가 내린 결과는 굳이 head.js를 써서 복잡도를 높여가며 성능을 향상시키려 애쓸 필요가 없다는 것이다.
그냥 <script> 태그를 </body>위에 두는 것 만으로도 훌륭한 효과를 볼 수 있다.

혹자는 말할것 같다. head.js에는 javascript 병렬 로딩 뿐만 아니라, 다른 JS들은 로딩 중이고, 특정 Javascript만 적재가 끝났을 때 어떠한 명령을 실행시키는게 가능하다고.
그런데.. 그걸 직접 해보시기 바란다.
내가 보기엔 유지보수 복잡도의 증가 때문에 견디기 힘들 상황이 될 듯하다.
그에 반해 얻는 속도의 이점은 고작 몇 ms 에 그칠 것이고 그나마도 브라우저 따라 오히려 느려지는 경우도 발생할 것 같다는게 내 예상이다.

자신의 사이트가 HTML보다는 Javascript를 더 많이 사용하는 (Google Map같은?) 그런 곳이라면 어쩌면 head.js를 사용하는 것이 나을지도 모른다. 하지만 내가 보기엔  HTML 출력이 더 중요한 일반적인 웹페이지에서는 저렇게 복잡도를 높여가며 Javascript 로딩 속도를 높이는게 의미가 있어보이진 않는다.

참조 : HTML5에는 async라고 head.js가 해주는 비동기 적재 역할을 표준으로 지원하는 옵션이 생겼다. 그리고 과거부터 있어온 defer라는 옵션은 <script>를 아래로 내리지 않고도 아래로 내린것과 같은 효과를 내게 해준다.(2012년 현재 모든 브라우저가 지원하지는 않고 있음)

테스트에 사용한 소스와 결과 데이터(ODS/Libre Office로 열어볼 것)는 첨부파일로 넣어 두었다.
scripttest.7z



tag : , , , , ,  ]]> 프로그래밍 javascript 병렬로딩 병렬적재 head.js script 성능 http://kwon37xi.egloos.com/4688068#comments Sun, 25 Mar 2012 08:52:52 GMT 권남 <![CDATA[ Annotation 인스턴스 생성하여 단위테스트하기 ]]> http://kwon37xi.egloos.com/4679620 http://kwon37xi.egloos.com/4679620
이것 때문에 처음에는 단위테스트에 별개의 비어있는 클래스와 메소드 등을 만들고 거기다 어노테이션을 원하는 조합으로 지정한 뒤에 그것을 리플렉션으로 어노테이션 인스턴스를 뽑아내서 사용했었는데, 역시나 뭔가 삽질 같았다.

그러다가 아주 당연한 것을 깨닫는다. Java의 어노테이션은 일종의 interface(@interface)이다! Create Annotation instance with defaults, in Java 참조

인터페이스이므로 클래스로 구현해서 인스턴스를 생성하면 되는 것이다.

아래와 같이 간결하게 해결이 된다. 그 외에 내가 썼던 해결책들은 http://wiki.kwonnam.pe.kr/java/annotation 에 함께 기록해 두었다.

// 아래와 같은 어노테이션이 있을 때!
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface LoginUser {
  boolean required() default true;
  SomeValue [] someValues() default {};
}
 
// 아래와 같이 클래스로 구현한 뒤에 해당 클래스의 인스턴스를 생성하면 된다.
public class FakeLoginUser implements LoginUser {
 
  private boolean requiredValue = true;
 
  private SomeValue[] someValueValue = {};
 
  public FakeLoginUser(boolean requiredValue, SomeValue[] someValueValue) {
    this.requiredValue = requiredValue;
    this.someValueValue = someValueValue;
  }
 
  @Override
  public Class<? extends Annotation> annotationType() {
    return LoginUser.class;
  }
 
  @Override
  public boolean required() {
    return requiredValue;
  }
 
  @Override
  public SomeValue[] someValue() {
    return someValueValue;
  }
}


tag : , , , ,  ]]> 프로그래밍 java interface annotation 어노테이션 애노테이션 http://kwon37xi.egloos.com/4679620#comments Tue, 28 Feb 2012 03:00:53 GMT 권남 <![CDATA[ Conditional Comment로 IE 브라우저별 CSS 읽어들이기 ]]> http://kwon37xi.egloos.com/4679120 http://kwon37xi.egloos.com/4679120 IE 버전에 따른 하위 호환성을 HTML만으로 구분을 보면 다음과 같은 방법으로 IE 하위버전에 대한 CSS를 관리하자고 제안하고 있다.
사실 이미 많이 쓰이는 방법이라 생각하는데, 더 많은 사람들이 이 방식을 사용했으면 해서 한 번더 글로 남긴다.

<link rel="stylesheet" href="/css/style.css" type="text/css">
<!--[if lt IE 7 ]><link rel="stylesheet" href="/css/ie6.css" type="text/css" /><![endif]--> 
<!--[if lt IE 8 ]><link rel="stylesheet" href="/css/ie7.css" type="text/css" /><![endif]--> 
<!--[if gte IE 8 ]><link rel="stylesheet" href="/css/ie8.css" type="text/css" /><![endif]-->

이 방법은, IE 버전별 핵을 써야하는 CSS를 따로 분리한 CSS 파일로 만들고 기본 style.css 에는 핵을 사용하지 않는 표준 문법을 준수하는 스타일만을 두는 방식이라고 보면 될 것 같다.

나는 이 방법을 매우 추천하는데 세 가지 이유가 있다.

1. 표준 준수 브라우저에서는 불필요한 CSS 파일을 적재할 필요가 없어지므로 성능이 향상된다.
2. IE의 과거버전에 대한 지원 중단시 ie6.css 파일을 삭제하고 Conditional Comments만 지우면 만사가 해결되는 유지보수성 확보.
3. 표준 스타일시트(여기서는 style.css)가 진짜로 표준을 준수했는지 확인이 쉬워진다.

사실 내가 가장 중요시 하는 점은 3번이다.
Firefox Web Developer 부가기능에는 자동으로 스타일시트가 표준을 준수했는지 실시간 확일을 해주는 기능이 있다. 물론 다른 브라우저에도 다 있을 것이다.

그런데, 이게 IE Hack과 표준을 모두 한 CSS에 섞어 쓰게 되면 IE Hack도 비표준이므로 오류로 잡아내게 된다. 이에 따라 처음에는 표준 문법 준수 여부를 잘 확인하다가도, 결국에는 수많은 IE Hack들 속에 섞여있는 잘못 작성한 CSS를 찾기가 어려워지면서 포기하게 된다(정확히 말하면 비표준 코드를 찾는 다기 보다는 오타 등으로 잘 못 작성한 CSS를 찾는 것이다).

이게 Condtional Comment를 사용하게 되면 IE에서만 IE Hack을 사용하는 코드가 적재되므로, 이 상황에서 발생한 비표준 CSS는 진짜로 코드를 잘 못짠 것임이 거의 확실하게 된다.

즉, 진짜 오류를 잡아내기가 쉬워지게 된다.

내가 정적인 언어를 더욱 선호하는 경향이 있는데, 이러한 이유중에 하나는 Compile Time Error Checking이 훨씬 더 쉽다는 강점 때문이다. 그런 면에서 HTML/CSS/Javascript는 나한테 별로 좋게 다가오는 프로그래밍 코드라고 보기는 어렵다.

그러나 방법을 찾아보면 이렇게 Compile Time 오류 검사를 철저하게 만들 수 있는 요소들이 나오게 된다. Javascript의 경우 "use strict"를 사용하고, CSS는 지금 이 글에서 말하는 방법.

HTML 같은 경우도 나 같은 경우 우리 프로젝트에서 Servlet Filter를 통해 reponse가 text/html일 경우 자동으로 HTML 5 Validator를 호출하여 Validation을 하는 환경을 구축하기도 했었다. 그러나 이 방법은 팀내 호응이 낮고, 속도도 느려서 일단은 제거했다.
HTML의 경우에는 브라우저가 특정 URL에 포함된 문서(즉, 개발/테스트 환경 URL)에 대해 무조건 HTML Validation을 해주는 플러그인이 나왔으면 하고 바라고 있다. (이미 나왔나??) -> 추가 있미 있다. Firefox Html Validator, Chrome Html Validator Chrome 용이 좀 더 좋은 듯.

그 외에도 동적인 언어의 경우 단위 테스트 강화를 통한 오류 검사 강화가 가능하겠다.

어.. 이상하다.. 말이 샜네.
암튼 오류는 되도록 실행시보다 Compile Time에 잡는게 좋겠다.
]]> 프로그래밍 http://kwon37xi.egloos.com/4679120#comments Sun, 26 Feb 2012 08:59:31 GMT 권남 <![CDATA[ [DEBUG] JPA/Hibernate LazyLoading이 설정이 안 먹을 때 간단한 추적 방법 ]]> http://kwon37xi.egloos.com/4679102 http://kwon37xi.egloos.com/4679102
즉, Lazy Loading 설정을 잘 마쳤으나, 분명히 Lazy Loading이 되어야 할 웹 페이지 호출 단계의 (컨트롤러나 서비스, 웹페이지) 어딘가에서 Lazy Loading 설정된 필드의 Getter 메소드가 호출된 상황일 경우가 많이 발생한다.

이 때 도대체 어디서 이노무 것이 호출 되었는지 알아내기가 번잡스럽다면 다음 방법을 써본다. 여기서는 엔티티 객체의 contents 필드가 Lazy Loading 설정되어진 상태라고 간주한다.

public String getContents() {
    try {
        throw new NullPointerException("getContents Lazy Loadign 추적");
    } catch(Exception ex) {
        ex.printStackTrace();
    }

    return contents;
}


즉, 일부러 예외를 발생시켜 getContents()가 호출 될 당시의 StackTrace를 통해서 getContents()를 호출한 코드의 계층 구조를 파악하는 것이다. 당연히 저 코드는 테스트후에 제거해야 한다. 안그러면 성능상에 상당한 불이익을 당하게 될 것이다.

StackTrace 읽는 것이야 다들 아실테니 패스.

그리고, 저기 보면 String에 대해서 Lazy Loading을 한 것처럼 했는데, 실제 Hibernate에서는 일반적인 방법으로는 String 필드의 Lazy Loading은 불가능하다. 이에 관해서는 네가지 정도의 방법이 있는데, 나는 주로 JPA One-To-One 게시판 형태에서 게시글에 대해 @ElementCollection을 사용한 LazyLoading 구현을 사용한다. 이 외에도 여러 방법이 있지만 복잡도가 높아지므로 @ElementCollection 방법을 권장한다.


tag : , , ,  ]]> 프로그래밍 java jpa hibernate lazyloading http://kwon37xi.egloos.com/4679102#comments Sun, 26 Feb 2012 08:14:19 GMT 권남 <![CDATA[ [DEBUG] Spring 3.0 -> 3.1 업그레이드시 발생한 오류 ]]> http://kwon37xi.egloos.com/4676081 http://kwon37xi.egloos.com/4676081 http://forum.springsource.org/showthread.php?122577-XML-Validation-Problems-A-schema-cannot-contain-two-global-components-with-the-same 참조

applicationContext*.xml 에서 다음과 같은 오류가 발생한다.

이유는 Spring-data-jpa 가 Spring 3.0 스키마에 대해 명시적 의존을 하는 상황이기 때문이라고 한다. 현재 이 버그는 Spring Data JPA에서 고쳐지긴 했는데, 문제는 정식 버전으로 아직 배포가 안된 상황이다. 곧 해결 될 듯.

유효성 검사에서만 오류가 발생하고 실제 사용에는 문제가 없다. Eclipse에서 XML/XSD 관련 유효성 검사를 끄면 에러를 안 볼 수 있다.

Error Description
--------------------------
The errors below were detected when validating the file "spring-context-3.0.xsd" via the file "applicationContext-jpa.xml". In most cases these errors can be detected by validating "spring-context-3.0.xsd" directly. However it is possible that errors will only occur when spring-context-3.0.xsd is validated in the context of applicationContext-jpa.xml.

Error
--------------------------
Description Resource Path Location Type
Referenced file contains errors (jar:file:/C:/Users/m061385/.m2/repository/org/springframework/spring-beans/3.1.0.RELEASE/spring-beans-3.1.0.RELEASE.jar!/org/springframework/beans/factory/xml/spring-beans-3.0.xsd). For more information, right click on the message in the Problems View and select "Show Details..." applicationContext-jpa.xml /boss/src/main/resources/META-INF/spring line 1 XML Problem

Error Details
--------------------------
sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of 'http://www.springframework.org/schema/beans,identifiedType'.
]]> 프로그래밍 http://kwon37xi.egloos.com/4676081#comments Thu, 16 Feb 2012 02:59:42 GMT 권남