MSFL :: 모리스 소프트웨어 공작소

APM (Application Performance Mangement) 과 관련해서 나오는 용어들 중에  APDEX라는 것이 있다. 보통 서비스 품질이라는 것은 IT 서비스를 제공하는 IT 부문과 IT 서비스를 이용하는 사용자 사이에 반응 시간 (Response Time)  등의 수치적인 지표를 이용해서 서로 수용 가능한 조건에서 이해하고 이용하는 기준으로 삼는 것이 필요하다. ITIL (IT Infrastructure Library) 에서는 이런 기준이 될 수 있는 지표들을 IT 부문이 관리하는 IT  기반의 기술적인 관점에서 측정 및 관리하려고 하는 반면에 "업무나 사용자 관점에서도 이런 지표들이 필요하지 않을까?" 하는 사고방식에 근거해서 나오는 서비스 관리를 APM이라고 할 수 있고, 이 APM을 실시하는 방법으로 APDEX (Application Performance inDEX) 라는 지표를 이용해서 "사용자 시점의 IT 서비스 관리가 ITIL 과 같이 표준 프로세스화 할 수 있는 것이 아닐까?" 라고 생각하고 이것을 추진하는 사람들이 모인 Apdex Alliance 라는 그룹이 미국에 등장했다. 업무나 사용자 관점에서 IT 서비스 관리를 비즈니스 서비스 매니지먼트 (BSM  - Business Service Management) 이라고 표현하고 이를 위해서는  ITIL 과점의 기술적인 서비스 매니지먼트 (TSM - Technical Service Management) 에 융합시켜 가는 것이 필요하다고 소개하고 있다. 그럼 Apdex Alliance 가 주창하고 있는 Apdex 지표는 무엇일까? Apdex 란? Apdex는 제공되는 IT 서비스에 대해 사용자의 만족도를 수치적인 지표로 잡을 수 있도록 하기 위한 것으로 측정된 데이터에 대해서 0 (불만족) ~ 1 (만족) 사이의 만족도를 표현하기 위한 것이다. 이 지표는 사용자가 실행하는 업무 (Task 라고 표현) 에서 측정된 각 반응 속도 (R

웹 어플리케이션을 개발할 때 Eclipse 에서 Servers 로 Tomcat을 등록해서 Web Application을 구동시키는 것이 일반적인 방법이다. 그러나 어떤 경우에는 지정한 포트가 이미 사용중이라는 오류를 만나게 될 수 있다. 이 상황을 구글에서 찾아보면 대부분의 해결 방법이 아래와 같이 제시된다. "사용중인 포트를 확인해서 사용 중인 다른 어플리케이션을 죽여라" 또는 "다른 포트로 변경해서 사용하라" C:\> netstat -ano | find "8080" C:\> taskkill /f /pid:... 일반적인 상황에서는 맞는 말이다. 그러나 제목에 언급한 것과 같이 "특정상황" 이 발생한 상황에서는 이런 해법은 전혀 도움이 되지 않는다. 여기서 말하는 특정 상황이라는 것은 Eclipse에서 Server 탭의 "Start" 버튼을 눌러서 실행을 하게 되면 다른 어플리케이션에서 사용하지 않는 포트임에도 불구하고 이미 사용중인 포트라는 오류가 발생한다는 것이다. 포트를 바꾸면 바꾼 포트가 사용중이라는 오류가 발생하게 된다. 위의 상황을 유추하면 Eclipse 가 Tomcat 구동 명령을 전달할 때 뭔가 문제가 있을 것 같다는 생각으로 해결법을 찾기 시작했지만 구글 검색을 통해서도 별다른 해결 방법을 찾지 못하고 있었다. 이런 상황에서는 대략 아래와 같은 특징들이 발생한다. 포트를 바꿔도 바뀐 포트로 사용중이라는 오류가 발생한다. Debug 모드로 실행하면 제대로 실행되는 경우가 있다. (그러나 Start 로 실행하면 오류가 발생한다) 처음 시스템을 부팅하고 JDK를 재 설치를 한 후에 Eclipse를 실행하면 제대로 실행된다. 단, 재 부팅하고 나면 다시 오류가 발생한다. (이 상황은 이해가 되지 않는다 ㅠㅠ) 더 많은 상황들이 존재하지만 딱히 연관되어 있다고 볼 수는 없기 때문에 생략하도록 한다. 위의 특징들 때문에

ByteCode 로 Instrumenation을 하던 중에 컴파일된 .class 파일을 통해서 사용된 JDK 의 버전을 찾아야 하는 상황이 발생했다. 여러 가지 방법을 찾던 중에 알게된 내용이 있어서 정리해 놓는다. .class 파일의 버전을 얻는 방법은 다음과 같다. > Unix/Linux 환경인 경우 javap -verbose MyClass | grep "major" > Windows 환경인 경우 javap -verbose MyClass | findstr "major" 위의 명령은 .class 에 설정되어 있는 메타 정보들 중에서 "major" 버전 정보를 읽은 것이다. 이 명령의 결과로 다음과 같이 정리할 수 있다. Java 1.2 를 사용한 경우에 Major 버전은 46 Java 1.3 을 사용한 경우에 Major 버전은 47 Java 1.4 를 사용한 경우에 Major 버전은 48 Java 5 를 사용한 경우에 Major 버전은 49 Java 6 을 사용한 경우에 Major 버전은 50 Java 7 을 사용한 경우에 Major 버전은 51 Java 8 을 사용한 경우에 Major 버전은 52 이 버전에 따라서 ClassWriter의 Verify 방법이 달라지게 된다. 따라서 Java 7 이전에 컴파일된 jar를 포함하여 사용하는 경우에 ByteCode 로 Instrumentation을 하는 경우라면 여러 가지 오류들 (Expand_Frames 옵션이 필요하다거나 ClassNotFoundException 등) 피하기 위해서 동적으로 운영할 수 있어야 한다. ByteCode Instrumentation (Using ASM) 을 할 경우에 해당 버전 정보를 대상 클래스에서 찾기 위해서는 아래의 명령을 사용하면 된다. ClassReader cr = new ClassReader(classFileBuffer); int majorVersion = cr.rea

현재 backbone, requirejs 를 사용하여 프로젝트를 진행 중이다. 클라이언트 사이드의 MVC 구현이다 보니 거의 대부분의 코드가 javascript 다. 스크립트 코드를 작성하면서 이전부터 궁금했던 것들을 하나씩 정리해 보도록 한다. 우선 첫번째로 == (Equality) 와 === (Identity) 의 차이를 이해해 보도록 한다. == 연산자는 left/right 가 다른 형식이면 형식을 강제로 변환하여 값이 같은지를 비교 한다. 그리고 값을 변환하여 비교하는 규칙은 복잡하고 외우기도 쉽지 않다. 반면에 === 연산자는 변환이 없이 있는 그대로를 비교하게 된다. 따라서 변환이라는 부하(?)를 주지 않기 위해서 단순한 비교라면 === 를 사용하는 것이 효과적이다. 다만 무분별하게 변수등을 선언해 놓고 비교한다면 오히려 헷갈릴수도 있으므로 조심해야 할 듯. 간략한 예제를 통해서 내용을 이해해 보도록 하자. var i = 0; console.log(i == '0');     >> true console.log(i === '0')    >> false 위의 코드를 보면 서로 다른 결과를 보여준다. 왜 이런 결과가 나오는지를 이해하면 된다. 변수 i 를 선언하고 0 을 배정했기 때문에 형식은 number 가 된다.  그런데 비교는 '0' 인 string 과 하고 있다. 따라서 == 연산에서는 string을 number로 변환한 후에 비교를 하게 된다. 그러니 값은 서로 같으므로 true 가 된다. 그러나 ===  연산은 값 뿐만 아니라 형식도 모두 비교하는 것이 때문에 (변환 과정이 없다) 값을 비교하기 이전에 형식이 다르므로 false 가 된다. '' == '0' 0 == '' 0 == '0' false == 'false' false == '0

현재 진행 중인 프로젝트에서 불특정하게 IOException이 발생하며 Session이 깨지는 증상이 있어서 로그를 확인해 보니 Sessions.ser 파일이 존재하는 폴더가 없는 문제가 발생하고 있었다. 대 부분 Eclilpse에서 서버를 운영하므로 해당 서버에서 server.xml 을 열고 다음과 같이 Context 내에 PersistentManager를 지정하면 해당 문제가 해결된다는 것이 구글에 많이 올라와 있다. <Context ...> <Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"/> </Context> 현재는 설정 후 동일 증상 발생여부를 확인하고 있다.

  검색을 해 보니 주로 많이 사용되는 Decompiler 가 JAD (JAva Decompiler) 이며, 기존 이클립스 3.x 와 현재 버전 4.x 에 따라서 설치 유무 또는 동작 유무가 다른 것 같다. 지금 현재 사용하는 버전은 Eclipse Kepler 는 버전이 4.3.2 인 것으로 보인다. JadClipse Plugin 설치   이클립스에서 Java Decompiler 를 사용하기 위해서는 2 개의 프로그램이 필요하다. JadClipse - Eclipse Plugin JAD - Java Decompiler   수동 설치 방법은 위의 페이지에서 정보를 따라서 설치하면 된다. 이번에는 "Eclipse Marketplace" 를 이용해서 설치하도록 한다. "Help > Eclipse Marketplace" 를 선택하고 검색어를 "decompiler" 라고 입력하면 아래의 그림과 같이 JadClipse 가 버전별로 보이게 된다.   이클립스 케플러의 버전이 4.x 이므로 JadClipse Plugin 도 4.0.0 으로 선택하고 "install" 버튼을 선택한다. (JadClipse 3.4.0 은 호환이 되지 않기 때문에 "install" 버튼이 존재하지 않는다)   "Confirm Selected Features" 창에서 선택한 기능을 보여주는 것이므로 "Confirm" 버튼을 눌러서 계속 진행하도록 한다.   "Review Licenses" 창에서 라이센스 수락 설정을 선택하고 "Finish" 버튼을 눌러서 설치 작업을 진행하도록 한다.   설치 작업 도중에 위의 그림과 같이 "Selection Needed" 창에서 인증여부를 선택하라는 내용이 보이고 "Chao Chen; ..." 이라는 것이 나타

  대표적인 프레임워크인 Spring Framework 을 자바환경에서 설정하는 방법을 정리해 보도록 한다. 실제로 구성해 본 적이 없기 때문에 자바 개발 초보의 입장에서 진행하도록 한다.   가장 먼저 할 작업은 이클립스를 설치하는 것이다. 이 글을 쓰는 시점에는 Eclipse Kepler JEE 버전을 사용하고 있다. 그러나 여러 가지 프로젝트를 구성하려고 한다면 JEE 버전의 이클립스를 사용하는 것이 좋다. 물론 다른 버전이라도 상관이 없을 듯 하다. (단지, 지원되지 않는 프로젝트 템플릿이 있다면 추가로 설정해야 하고 필요한 것들을 설치해야 하는 수고가 따른다. 근데 버전이 굉장히 많구나.. -_-) 설치가 다 되어 환경 설정이 끝난 상태라면 이클립스를 실행하도록 한다. Install Spring IDE Plugin   실행된 이클립스에서 아래와 같이 새로운 소프트웨어 설치 메뉴를 실행하도록 한다.   아래와 같이 열린 "설치" 다이얼로그 화면에서 "Work with" 항목에 있는 "Add" 버튼을 누른다. 다른 옵션들은 별도로 변경하지 않는다.   열린 "Add Repository" 다이얼로그 화면에서 아래와 같이 Name 과 Location 값을 입력한다.   "OK" 버튼을 누르면 지정한 정보에 속하는 활용 가능한 플러그인 목록이 보여지게 된다. 아래와 같이 기본적인 선택을 하도록 한다. (Integrations / Spring IDE, Uncategorized 를 선택하지 않는 이유는 선행 설치가 필요한 다른 플러그인을 요구하며, 현재로서는 그다지 큰 필요가 없기 때문이다. 향후에 다시 설치가 가능하다)   "Next" 버튼을 누르면 아래의 그림과 같이 설치될 내용이 보여지게 된다.   위의 설치 목록을 보면 "Will not be installed" 와 &quo