RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
'분류 전체보기'에 해당되는 글 379


< 원인 >

형상관리 이력정보가 꼬이는 경우가 있음.


< 해결 >

1-1. 해당 프로젝트를 선택하고 우클릭 > team > cleanup 실행

1-2. cleanup 성공 후 다시 업데이트


클린업 도중 에러가 발생하거나 위 방법으로 해결이 안되면 다음과 같이 처리

2-1. 탐색기에서 콘솔로그에 출력된 폴더 내에 있는 .svn 폴더로 이동


2-2. 폴더 내에 locked 파일이 있으면 삭제

2-3. 이클립스에서 다시 업데이트

2010/02/01 16:02 2010/02/01 16:02
이 글에는 트랙백을 보낼 수 없습니다
MYSQL 테이블을 가변적으로 사용할때 쓰면 편리하다

SET
@table = 'mysql.user';
SET @host = '''%localhost%''';
SET @s = CONCAT('SELECT * FROM ', @table, ' WHERE host LIKE ', @host);
PREPARE stmt FROM @s;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

음..
2010/01/05 11:53 2010/01/05 11:53
이 글에는 트랙백을 보낼 수 없습니다
분류없음  2009/12/09 14:16

JVM Options

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[숨기기]

[편집] 개요

[편집] 왜 JVM Option을 알아야 하는가

Java 언어는 하드웨어/OS에 독립적이다. 즉, Java로 작성된 Application은 아무런 수정없이 JVM이 구동가능한 어떤 OS에서도 동작한다. 하지만 이것은 "동작"의 독립성일 뿐 "성능"의 독립성이 아니다.

특정 OS의 특정 JDK 버전에서 아무런 성능 문제없이 구동되었던 Application이 다른 OS나 다른 버전의 JDK에서는 심각한 성능 문제를 겪는 사례가 종종 있다. Java 언어와 Bytecode는 독립성을 가지고 있지만, Bytecode를 실행하는 JVM은 그렇지 않기 때문이다. 이러한 종류의 성능 문제를 해결하려면 JVM이 제공하는 Options들에는 어떤 것이 있고 Option의 적용에 따라 어떤 차이가 나타나는지 정확하게 이해해야 한다.


[편집] Standard vs. Non-Standard Option

Standard Option은 JVM 표준이다. 즉 Sun HotSpot JVM, IBM JVM, BEA JRockit JVM, HP HotSpot JVM 등 모든 JVM이 동일한 Option을 제공한다.

반면 Non-Standard Option은 JVM의 표준이 아니다. 따라서 JVM의 버전과 OS 종류에 따라 존재여부가 결정된다. 언제든지 추가되거나 없어지기도 한다. 이런 면에서 Non-Standard Option들은 골칫거리처럼 여겨질 수 있다. 하지만, 다음과 같은 측면에서 반드시 필요한 존재이기도 하다.

  • JVM 구동에 필요한 설정값(Configuration Value)를 지정할 수 있다.
  • 성능 개선에 필요한 Parameter 값을 지정할 수 있다.
  • Bug나 오동작에 의한 Workaround로 활용할 수 있다.

Non-Standard Option을 모르더라도 Java Application을 작성하고 구동하는데 전혀가 문제가 없을 수도 있다. 하지만 조그만한 오동작이나 성능 저하만 발생해도 Non-Standard Option 도움 없이는 해결할 수 없는 경우가 많다. 따라서 시스템 관리자나 개발자들은 중요한 Non-Standard Option들에 대해 어느 정도 이해하고 있어야 한다.

Non-Standard Option은 다음 두 개의 범주로 구분된다.

  • -X Option: 일반적인 Non-Standard Option이다. Macro한 측면에서의 JVM 제어 기능을 제공한다. -X Option은 JVM마다 다르지만 일부 Option들은 마치 Standard Option처럼 사용된다.
  • -XX Option: -X Option보다 보다 세밀한 제어 기능을 제공한다. Micro한 측면에서의 JVM 기능을 제공한다. 세밀한 성능 튜닝이나 버그에 대한 Workaround를 위해서 주로 활용된다. -XX Option은 JVM 종류에 따라 완전히 다르다.

[편집] Option 지정하기

JVM Option을 지정하는 방법의 예는 다음과 같다.

  1. 단일값: -client Option과 같이 옵션을 지정하면 그 자체로 의미를 지닌다.
  2. 크기(Size): -Xmx1024m과 같이 크기(K,M,G)를 지정한다.
  3. 숫자(Int): -XX:SurviorRatio=10과 같이 숫자값을 지정한다.
  4. 문자열(String): -agentlib:hprof=cpu=samples과 같이 문자열을 지정한다.
  5. Boolean: -XX:+PrintGCDetails 혹은 -XX:-PrintGCDetails와 같이 +/-를 이용해서 활성화/비활성 여부를 지정한다.

[편집] Sun HotSpot JVM (1.5 기준)

[편집] Standard Options

Option Description
-client Client HotSpot JVM을 사용한다. Client HotSpot JVM은 Desktop용 Application을 구동하는데 유리하다. 성능 최적화(Optimization) 과정을 간략화함으로써 Application의 시작 시간을 최소화한다.
-server Server HotSpot JVM을 사용한다. Server HotSpot JVM은 Server용 Application을 구동하는데 유리하다. 성능 최적화(Optimization)에 필요한 모든 과정을 최대한으로 수행한다. Application의 시작 시간은 느리지만, 일정 시간이 흐르면 Client HotSpot JVM에 비해 훨씬 뛰어난 성능을 보장한다.

(참고)Jdk 1.5부터는 Server-Class 머신인 경우에는 -server 옵션이 기본 적용된다. Server-Class 머신이란 2장 이상의 CPU와 2G 이상의 메모리를 갖춘 머신을 의미한다.

-d32 32bit JVM을 사용한다. 32bit JVM은 메모리를 최대 2G까지만 사용할 수 있다. 반면 일반적인 수행 성능 64bit JVM에 비해 뛰어난 경우가 많다. 따라서 큰 크기의 Java Heap을 사용하지 않는 경우에는 비록 64bit 머신이라고 하더라도 32bit JVM을 사용하는 것이 권장된다.
-d64 64bit JVM을 사용한다. 64bit JVM에서 사용가능한 메모리의 크기에는 사실상 제한이 없다. 대형 Application들의 경우 수G ~ 수십G의 Java Heap을 사용하는 경우가 많다.
-agentlib:<libname>[=<options>] Native Agent Library를 로딩한다. Native Agent Library란 JVMPI/JVMTI를 구현한 Library를 의미하며 C/C++/OAK 로 구현된다. JVM은 Unix/Linux에서는 lib<libname>.so 파일이, Windows에서는 <libname>.dll 파일을 탐색한다. 해당 파일은 현재 Directory나 PATH 변수에 등록된 Directory에 존재해야 한다.

(참조) JDK 1.4까지는 HProf를 실행시키기 위해 -Xrunhprof:option=value 옵션을 사용한다. JDK 1.5부터는 -Xagentlib:hprof=option=value 옵션이 권장된다. -Xrunhprof 옵션은 차후 없어질 수 있다.

-agentpath:<pathname>[=<options>] -agentlib 옵션과 동일한 기능이다. Library 이름 대신 Full Path 명을 준다.
-javaagent:<jarpath>[=<options>] Java Agent Library를 로딩한다. Java Agent는 Native Agent가 C/C++/OAK 로 구현되는 것과 달리 Java로 구현된다. java.lang.instrument Package를 통해 Java Agent를 구현하는 필요한 Interface가 제공된다. Java Agent는 BCI를 통해 Runtime에 Class들의 Bytecode를 변경하는 방법을 통해 작업을 수행한다.

[편집] Non-Standard Options (-X)

Option Description
-Xbootclasspath[/a|/p]:<path> Boot class path를 제어한다. /a 옵션은 Boot class path의 제일 뒤에 Append, /p 옵션은 제일 앞에 Prepend한다. 일반적인 환경에서는 Boot class path를 제어할 필요가 없다. Java Core Library(rt.jar 등)등에 대해 Reverse Engineering을 수행하고 행동 방식을 변경하고자 할 경우에 주로 활용된다.
-xcheck:jni
-Xint Intepreter 모드로만 ByteCode를 실행한다. Interpreter 모드로 실행될 경우에는 JIT Compile 기능이 동작하지 않는다. 이 옵션을 활성화하면 실행 속도이 다소 저하될 수 있다. 따라서 HotSpot Compiler의 버그로 문제가 생길 때만 사용이 권장된다.
-Xnoclassgc Class Garbage Collection을 수행하지 않는다.
-Xloggc:<file> GC Log를 기록할 파일명을 지정한다. 파일명을 지정하지 않으면 Standard Out이나 Standard Error 콘솔에 출력된다. 주로 -XX:+PrintGCTimeStamps, -XX:+PrintGCDetails 옵션과 같이 사용된다.
-Xmixed Mixed 모드로 ByteCode를 실행한다. HotSpot JVM의 Default 동작 방식이며, -Xint 옵션과 상호 배타적인 옵션이다.
-Xmn<size> Young Generation이 거주하는 New Space의 크기를 지정한다. 대개의 경우 이 옵션보다는 -XX:NewRatio 옵션이나 -XX:NewSize 옵션을 많이 사용한다.
-Xms<size> Java Heap의 최초 크기(Start Size)를 지정한다. Java Heap은 -Xms 옵션으로 지정한 크기로 시작하며 최대 -Xmx 옵션으로 지정한 크기만큼 커진다. Sun HotSpt JVM 계열에서는 최초 크기와 최대 크기를 동일하게 부여할 것을 권장한다. 크기의 동적인 변경에 의한 오버 헤드를 최소화하기 위해서이다.
-Xmx<size> Java Heap의 최대 크기(Maximum Size)를 지정한다. Java Heap은 -Xms 옵션으로 지정한 크기로 시작하며 최대 -Xmx 옵션으로 지정한 크기만큼 커진다. Sun HotSpt JVM 계열에서는 최초 크기와 최대 크기를 동일하게 부여할 것을 권장한다. 크기의 동적인 변경에 의한 오버 헤드를 최소화하기 위해서이다.
-Xrunhprof[:help][:option=value,...] HProf(Heap and CPU Profiling Agent)를 실행한다. HProf는 JVMPI/JVMTI를 이용해 구현된 Sample Profiler이다. 비록 Sample에 불과하지만, 많은 경우 HProf만으로도 상당히 유용한 정보들을 얻을 수 있다.
-Xrs OS Signal사용을 최소화한다. 가령 이 옵션을 켜면 kill -3 [pid] 명령을 수행해도 Thread dump가 발생하지 않는다.
-Xss<size> 개별 Thread의 Stack Size를 지정한다. 예를 들어 Thread Stack Size가 1M이고, Thread가 최대 100개 활성화된다면, 최대 100M의 메모리를 사용하게 된다. 대부분의 경우 기본값(Default)을 그대로 사용하는 것이 바람직하다. 많은 수의 Thread를 사용하는 Application의 경우 Thread Stack에 의한 메모리 요구량이 높아지며 이로 인해 Out Of Memory Error가 발생할 수 있다. 이런 경우에는 -Xss 옵션을 이용해 Thread Stack Size를 줄여주어야 한다.

[편집] Non-Standard Options (-XX)

-XX 옵션 중 Boolean 유형은 접두어로 +를 붙이면 활성화(Enable), -를 붙이면 비활성화(Disable)를 의미한다.

Option Default Description
-XX:+AggressiveHeap False 말 그대로 Heap을 Aggressive(공격적)하게 사용하는 옵션이다. 이 옵션이 활성화되면 JVM은 현재 Application을 Memory-Intensive한 것으로 간주하고 Heap 공간을 최대한 사용하게끔 관련된 다른 옵션 값들을 결정한다. 가령 UseParallelGC 옵션을 활성화시키고, Java Heap의 크기를 Physical Memory의 최대치에 가깝게 설정한다.
이 옵션은 비록 사용하기는 간편하지만, 일반적으로 잘 사용되지는 않는다. 대부분의 경우, 개별적인 옵션들을 이용해 좀 더 세밀한 튜닝을 시도한다.
-XX:+CMSClassUnloadingEnabled False CMS CollectorPermanent Generation에 대해 GC 작업을 수행하지 않으며, Class 메타데이터에 대한 Unloading 작업 또한 수행하지 않는다. 따라서 Application의 특성상 많은 수의 Class를 동적으로 생성하고 Loading하는 경우에는 Permanent Generation에서 Out Of Memory Error가 발생할 수 있다. 이런 경우에는 이 옵션과 함께 CMSPermGenSweepingEnabled 옵션을 사용해서 Permanent Generation에 대한 GC 작업과 Class Unloading 작업을 활성화한다. JDK 1.5까지는 이 두 옵션을 모두 활성화해야 Class Unloading이 이루어진다. JDK 1.6부터는 CMSPermGenSweepingEnabled 옵션을 활성화하지 않아도 이 옵션이 작동한다.
-XX:CMSFullGCsBeforeCompaction=<value> -1 CMS Collector에서 Compaction(압축)을 수행하기 전에 Full GC를 수행할 회수를 지정한다. 일반적인 Full GC는 Compaction 작업을 수반한다. 반면에 CMS CollectorFull GC는 Compaction을 수행하지 않는다. 이로 인해 Heap의 Fragmentation이 발생할 수 있지만, Full GC에 의한 Pause Time을 최소화할 수 있다는 장점이 있다.

이 옵션은 Compaction의 발생 시점을 제어하는 역할을 한다. 예를 들어 이 값이 "1"인 경우, Concurrent Full GC가 아직 종료되지 않은 시점에 새로운 Concurrent Full GC 작업이 시작되면(1), Compaction이 수반된다. 만일 이 값이 "0"인 경우에는 Concurrent Full GC는 "항상" Compaction을 수반한다. 따라서 CMS Collector를 사용하는 환경에서 Heap Fragmentation에 의한 문제가 발생하는 경우에는 "0"의 값을 부여하는 것이 Workaround가 될 수 있다.

-XX:+CMSIncrementalMode False Full GC 작업을 Incremental하게 진행한다. 일반적으로 CMS CollectorOld Generation가 어느 정도 이상 점유되면 Concurrent Full GC 작업을 시작한다. 반면 이 옵션이 활성화되면 Old Generation의 사용률과 무관하게 백그라운드에서 점진적으로(Incremental) Old Generation에 대한 GC 작업을 수행한다. 이 옵션을 사용하면 CMSInitiatingOccupancyFraction 옵션은 무시된다.

이 옵션을 활성화하면 Throughput은 다소 줄어들고, Response Time은 좀 개선되는 경향이 있다. 따라서 GC 작업 Pause를 더 줄이고 싶을 경우에 사용할 수 있다.

-XX:CMSInitiatingOccupancyFraction=<value> -1 CMS Collection이 시작되는 임계값을 결정한다. 만일 이 값이 "50"이면 Old Generation이 50% 이상 사용되면 Concurre Full GC가 시작된다. 이 값의 기본값은 "-1"이다. 이 경우에는 CMSTriggerRatio 옵션과 MinHeapFreeRatio 옵션이 임계치로 사용된다. 임계치의 계산 공식은 다음과 같다.

Start Ratio = 100-MinHeapFreeRatio(=40) + MinHeapFreeRatio(=40) * (CMSTriggerRatio(=80)/100) = 92
즉, CMSInitiatingOccupancyFraction 옵션이 지정되지 않으면 Old Generation이 92% 정도 사용될 때 Concurrent Full GC가 시작된다.
이 옵션을 지정하면 50%에서 시작하여, 옵션으로 지정된 값까지 점진적으로 임계값을 조정한다. 만일 임계값을 고정하고자 할 경우에는 UseCMSInitiatingOccupancyOnly 옵션을 활성화해야 한다.
이 옵션의 값이 작으면 CMS Collection이 그만큼 빨리 동작하기 때문에 Promotion Failure에 의한 Stop The World GC 작업이 발생할 확률이 그만큼 줄어든다.

-XX:+CMSPermGenSweepingEnabled False CMS Collector는 기본적으로 Permanent Generation에 대해 Collection을 수행하지 않는다. 따라서 많은 수의 Class를 Loading하는 경우 Out Of Memory Error가 발생할 수 있다. 이 옵션을 활성화하면 Permanent Generation에 대한 Collection을 수행한다. JDK 1.5까지는 이 옵션과 함께 CMSClassUnloadingEnabled 옵션을 활성화해야 동작한다.
-XX:CompilerCommandFile=<file> .hotspot_compiler Compiler Command File의 위치를 지정한다.
-XX:+DisableExplicitGC False System.gc 호출에 의한 Explicit GC를 비활성화한다. RMI에 의한 Explicit GC나 Application에서의 Explicit GC를 원천적으로 방지하고자 할 경우에 사용된다.
-XX:GCHeapFreeLimit=<Percentage> 5 Parallel Collector를 사용할 때 GC도중 Out Of Memory Error의 발생을 방지하는데 도움을 준다. GC로 확보해야할 Free Space의 하한선을 결정한다. 이 값은 Max Heap 크기에 대한 Free 공간 크기의 비율이며 기본값은 "5"이다. 즉 Parallel Collection 후 확보해야할 Free 공간 크기가 적어도 Max Heap 크기의 5% 이상이 되도록 보장하는 것이다.
-XX:GCTimeLimit=<Percentage> 90 Parallel Collector를 사용할 때 GC도중 Out Of Memory Error의 발생을 방지하는데 도움을 준다. 전체 JVM 수행시간 대비 Parallel Collection 수행 시간의 상한선를 결정한다. 기본값은 "90"이다. 즉 Parallel Collection이 전체 수행 시간의 90%까지 사용할 수 있게 된다.
-XX:+HeapDumpOnOutOfMemoryError False Out Of Memory Error가 발생하면 Heap Dump를 File에 기록한다. JDK 1.6 부터 지원되는 옵션이다.
-XX:MaxGCMinorPauseMillis=<Value> None Minor GC에 의한 Pause Time을 <value>ms 이하가 되게끔 Heap 크기와 기타 옵션들을 자동으로 조정하는 기능을 한다. 이 값은 목표값(Target)이지 고정값이 아니다. Minor GC에 의한 Pause Time이 길 경우에 Workaround로 사용할 수 있다.
-XX:MaxGCPauseMillis=<Value> None GC에 의한 Pause Time을 <value>ms 이하가 되게끔 Heap 크기와 기타 옵션들을 자동으로 조정하는 기능을 한다. MaxGCMinorPauseMillis 옵션과 마찬가지로 목표값으로서의 역할을 한다. GC에 의한 Pause Time이 길 경우에 Workaround로 사용할 수 있다.
-XX:MaxHeapFreeRatio=<Value> 70 Heap Shrinkage를 수행하는 임계치를 지정한다. 예를 들어 이 값이 70이면 Heap의 Free 공간이 70% 이상이 되면 Heap 크기가 축소된다. MinHeapFreeRatio 옵션과 함께 Heap의 크기 조정을 담당한다.
-XX:MaxNewSize=<Value> None Young Generation의 최대 크기를 지정한다. Young Generation의 시작 크기는 NewSize 옵션에 의해 지정된다.
-XX:MaxPermSize=<Value> None Permanent Generation의 최대 크기를 지정한다. Permanent Generation의 시작 크기는 PermSize 옵션에 의해 지정된다. 많은 수의 Class를 Loading하는 Application은 PermSizeMaxPermSize 옵션을 이용해 Permanent Generation의 크기를 크게 해주는 것이 좋다. Permanent Generation의 크기가 작을 경우에는 Out Of Memory Error가 발생할 수 있다.
-XX:MinHeapFreeRatio=<Value> 40 Heap Expansion을 수행하는 임계치를 지정한다. 예를 들어 이 값이 40이면 Heap의 Free 공간이 40% 미만이 되면 Heap 크기가 확대된다. MaxHeapFreeRatio 옵션과 함께 Heap의 크기 조정을 담당한다.
-XX:NewRatio=<Value> OS/JDK Version마다 다름 Young GenerationOld Generation의 비율을 결정한다. 예를 들어 이값이 2이면 Young:Old = 1:2 가 되고, Young Generation의 크기는 전체 Java Heap의 1/3이 된다.
-XX:NewSize=<Value> OS/JDK Version마다 다름 Young Generation의 시작 크기를 지정한다. Young Generation의 크기는 NewSize 옵션(시작 크기)과 MaxNewSize 옵션(최대 크기)에 의해 결정된다.
-XX:OnError=<Command> None Fatal Error가 발생할 경우(예: Native Heap에서의 Out Of Memory Error), <Command>로 지정된 OS 명령문을 수행한다. 비정상적인 JVM 장애 현상을 좀 더 자세하게 분석하고자 할 경우에 주로 사용된다.
-XX:OnError="pmap %p" 
 --> JVM에서 Fatal Error가 발생하면 Process ID에 대해 pmap 명령을 수행한다.
-XX:OnOutOfMemoryError=<Command> None Out Of Memory Error가 발생할 경우, <Command>로 지정된 OS 명령문을 수행한다. JDK 1.6에 추가된 옵션으로, Out Of Memory Error가 Java에서 얼마나 보편적으로 발생하는지를 알 수 있다.
-XX:OnOutOfMemoryError="pmap %p" 
 --> JVM에서 Fatal Error가 발생하면 Process ID에 대해 pmap 명령을 수행한다.
-XX:ParallelGCThreads=<value> CPU 개수 Parallel Collector를 사용할 경우, GC작업을 수행할 Thread의 개수를 지정한다. 기본값은 CPU 개수이다. 즉, Parallel GC 작업을 수행하기 위해 시스템 전체의 CPU를 최대한 활용한다. 하나의 Machine에 여러 개의 JVM을 구동하는 환경이나, 하나의 Machine을 여러 종류의 Application이 공유해서 사용하는 환경에서는 이 옵션의 값을 낮게 설정해서 GC Thread의 개수를 줄임으로써 성능 개선을 꾀할 수 있다. Context Switching에 의한 성능 저하를 막을 수 있기 때문이다.
-XX:PermSize=<size> Permanent Generation의 최초 크기를 지정한다. Permanent Generation의 최대 크기는 MaxPermSize 옵션에 의해 지정된다. 많은 수의 Class를 로딩하는 Application은 큰 크기의 Permanent Generation을 필요로 한며, Permanent Generation의 크기가 작아서 Class를 로딩하는 못하면 Out Of Memory Error가 발생한다.
-XX:PretenureSizeThreshold=<value> 0 일반적으로 Object는 Young Generation에 최초 저장된 후 시간이 흐름에 따라 Tenured Generation으로 Promotion된다. 하지만, Object의 크기가 Young Generation보다 큰 경우 JVM은 Old Generation에 Object를 직접 저장하기도 한다. PretenuredSizeThreshold 옵션을 이용하면 Young Generation을 거치지 않고 직접 Old Generation에 저장하게끔 할 수 있다. 가령 이 옵션의 값이 1048576(1M)이면, 1M 크기 이상의 오브젝트는 Old Generation에 바로 저장된다.

큰 크기의 오브젝트를 Old Generation에 직접 저장함으로써 불필요한 Minor GC를 줄이고자 하는 목적으로 사용된다.

-XX:+PrintGCApplicationStoppedTime False Application에서 Stop이 발생한 경우 소요된 시간 정보를 기록한다. 이 시간은 GC 작업 자체에 의한 Stop 뿐만 아니라 JVM의 내부적인 이유로 Application Thread들을 Stop 시킨 경우를 포함한다.
-XX:+PrintGCDetails False GC 발생시 Heap 영역에 대한 비교적 상세한 정보를 추가적으로 기록한다. 추가적인 정보는 {GC 전 후의 Young/Old Generation의 크기, GC 전 후의 Permanent Generation의 크기, GC 작업에 소요된 시간} 등이다. Minor GC가 발생한 경우 PrintGCDetails 옵션의 적용 예는 아래와 같다.
[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]]

위의 로그가 의미하는 바는 다음과 같다.

  • GC 전의 Young Generation Usage = 64M, Young Generation Size = 64M
  • GC 전의 Total Heap Usage = 196M, Total Heap Size = 260M
  • GC 후의 Young Generation Usage = 9.5M
  • GC 후의 Total Heap Usage = 133M
  • Minor GC 소요 시간 = 0.0457646 초

Major GC가 발생한 경우 PrintGCDetails 옵션의 적용 예는 아래와 같다.

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]
111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

위의 로그는 Minor GC 정보 외에 다음과 같은 Major GC 정보를 제공한다.

  • GC 전의 Tenured Generation Usage = 18M, Tenured Generation Size = 24M
  • GC 후의 Tenured Generation Usage = 2.3M
  • Major GC 소요시간 = 0.12초

(참고) PrintGCDetails + PrintGCTimeStamps 옵션의 조합이 가장 보편적으로 사용된다.

-XX:+PrintGCTimeStamps False GC가 발생한 시간을 JVM의 최초 구동 시간 기준으로 기록한다.

(참고) PrintGCDetails + PrintGCTimeStamps 옵션의 조합이 가장 보편적으로 사용된다.

-XX:+PrintHeapAtGC Fasle GC 발생 전후의 Heap에 대한 정보를 상세하게 기록한다. PrintHeapAtGC 옵션과 PrintGCDetails 옵션을 같이 사용하면 GC에 의한 Heap 변화 양상을 매우 정확하게 파악할 수 있다. 아래에 PrintHeapAtGC 옵션의 적용 예가 있다.
0.548403: [GC {Heap before GC invocations=1:
Heap
par new generation total 18432K, used 12826K [0xf2800000, 0xf4000000, 0xf4000000]
eden space 12288K, 99% used<1> [0xf2800000, 0xf33ff840, 0xf3400000]
from space 6144K, 8% used<2> [0xf3a00000, 0xf3a87360, 0xf4000000]
to space 6144K, 0% used<3> [0xf3400000, 0xf3400000, 0xf3a00000]
concurrent mark-sweep generation total 40960K, used 195K<4>[0xf4000000, 0xf6800000, 0xf6800000]
CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]
concurrent-mark-sweep perm gen total 4096K, used 1158K<5> [0xf6800000, 0xf6c00000, 0xfa800000]
CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]
0.549364: [ParNew: 12826K<6>->1086K<7>(18432K<8>), 0.02798039 secs] 13022K->1282K(59392K)
Heap after GC invocations=2:
Heap
par new generation total 18432K, used 1086K [0xf2800000, 0xf4000000, 0xf4000000]
eden space 12288K, 0% used<10> [0xf2800000, 0xf2800000, 0xf3400000]
from space 6144K, 17% used<11> [0xf3400000, 0xf350fbc0, 0xf3a00000]
to space 6144K, 0% used<12> [0xf3a00000, 0xf3a00000, 0xf4000000]
concurrent mark-sweep generation total 40960K, used 195K<13> [0xf4000000, 0xf6800000, 0xf6800000]
CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]
concurrent-mark-sweep perm gen total 4096K, used 1158K<14> [0xf6800000, 0xf6c00000, 0xfa800000]
CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]
} , 0.0297669 secs]
-XX:SoftRefLRUPolicyMSPerMB=<value> 1000(ms) Soft ReferenceJava Heap에서 밀려나는 주기를 설정한다. 기본값이 1000ms(1초)이다. JDK 1.3.1까지는 Soft Reference는 GC 작업 발생시 항상 메모리에서 해제되었다. 하지만 이후 버전에서는 Free Memory에 비례해 일정 시간 정도 메모리에 보관하게끔 변경되었다. 가령 이 값이 1000(1초)이면, Heap의 Free Memory 1M마다 바로 직전에 참조된 시간에서 1초가 지나지 않았다면 메모리에서 해제하지 않는다.

이 값을 크게 부여하면 Soft Reference가 그만큼 오래 메모리에 머물고 사용 효율이 높아진다. 반면 메모리 점유율이 높아진다. 따라서 Applicaiton에서 Soft Reference를 많이 사용하고, Free Memory가 많지 않은 상황에서는 이 값을 낮출 필요가 있다. 반면 Soft Reference에 기반하여 Cache를 구현하고, Free Memory에 여유가 있는 상황에서는 이 값을 높임으로써 성능 향상을 꾀할 수 있다.

-XX:SurvivorRatio=<value> 5~6(OS/Version마다 다름) Survivor SpaceEden Space의 비율을 지정한다. 만일 이 값이 6이면, To Survivor Ratio:From Survivor Ratio:Eden Space = 1:1:6이 된다. 즉, 하나의 Survivor Space의 크기가 Young Generation의 1/8이 된다. Survivor Space의 크기가 크면 Tenured Generation으로 옮겨가지 전의 중간 버퍼 영역이 커지는 셈이다. 따라서 Full GC의 빈도를 줄이는 역할을 할 수 있다. 반면 Eden Space의 크기가 줄어들므로 Minor GC가 자주 발생하게 된다.
-XX:+TraceClassLoading False Class Loading을 추적하는 메시지를 뿌릴지의 여부를 지정한다. TraceClassUnloading 옵션과 함께 ClassLoader 문제를 추적하고자 할 때 사용된다.
-XX:+TraceClassUnloading False Class Unloading을 추적하는 메시지를 뿌릴지의 여부를 지정한다. TraceClassLoading 옵션과 함께 ClassLoader 문제를 추적하고자 할 때 사용된다. 이 옵션은 JDK 1.6에서 추가되었다.
-XX:+UseAdaptiveSizePolciy True Parallel Collector를 사용할 경우 Young Generation의 크기를 Adaptive하게 적용할 지의 여부를 지정한다. Parallel Collector의 목적은 Throughput을 최대화하는 것이며, 이 목적에 따라 Young Generation의 크기를 JVM 스스로 조정한다.

(주의) Adaptive Size를 사용하는 경우 Young Generation의 크기가 잘못 계산되어 Full GC를 과잉 유발하는 것과 같은 오동작을 하는 경우가 있다. 이럴 경우에는 이 옵션의 값을 False(-XX:-UseAdaptiveSizePolicy)로 변경해주어야 한다.

-XX:+UseCMSCompactAtFullCollection True CMS Collector에 의한 Concurrent GC 수행 시 Compaction 작업을 수행할 지의 여부를 지정한다. 이 값이 True이면, Old Generation의 Fragmentation에 의해 Promotion Failure가 발생할 때 Stop The World 방식의 Full GC를 수행하며 Compaction이 이루어진다. JDK 1.4.2부터는 True가 Default 값이다. 좀 더 자세한 내용은 CMSFullGCsBeforeCompaction 파라미터를 참조한다.
-XX:+UseCMSInitiatingOccupancyOnly False Concurrent Full GC를 수행할 기준으로 최초에 지정된 비율을 고정적으로 사용할지의 여부를 지정한다. 최초의 비율은 CMSInitiatingOccupancyFraction 옵션에 의해 지정된다.

CMS Collector를 사용하는 환경에서 Full GC가 자주 발생하는 경우 CMSInitiatingOccupancyFraction 옵션의 값을 낮게(50이하)로 지정하고, 이 옵션의 값을 True로 지정하는 방법을 많이 사용한다.

-XX:+UseConcMarkSweepGC False CMS Collector를 사용할 지의 여부를 지정한다. GC Pause에 의한 사용자 응답 시간 저하 현상을 줄이고자 할 경우에 사용이 권장된다.
-XX:+UseParallelGC 환경에 따라 다름 Parallel Collector를 사용할 지의 여부를 지정한다. JDK 1.4까지는 False가 기본값이다. JDK 1.5부터는 서버급 머신인 경우에는 True, 클라이언트급 머신일 경우에는 False가 기본값이다. 서버급 머신이란 CPU가 2개 이상, Physical RAM이 2G 이상인 머신을 의미한다. 큰 크기의 Young Generation이 일반적인 엔터프라이즈 환경에서는 Parallel Collector를 사용함으로써 Minor GC에 의한 GC Pause를 최소화할 수 있다. Parallel CollectorYoung Generation에 대해서만 작동한다는 사실에 주의하자. Old Generation에 대해 Parallel Collection을 사용하고자 하는 경우에는 UseParallelOldGC 옵션을 사용한다.
-XX:+UseParallelOldGC False Old Generation에 대해 Parallel Collection을 수행할 지의 여부를 지정한다. JDK 1.6에서 추가된 옵션이다.
-XX:+UseParNewGC 환경에 따라 다름 CMS Collector를 사용하는 경우에 한해서, Young Generation에 대해서 Parallel Collection을 수행할 지의 여부를 지정한다. 이 옵션과 UseParallelGC, UseParallelOldGC 옵션과의 차이를 명확하게 구분해야 한다.
-XX:+UseSerialGC 환경에 따라 다름 Serial Collector를 사용할 지의 여부를 지정한다. JDK 1.4까지는 Default 값이 True이다. JDK 1.5에서는 UseParallelGC 옵션에서 설명한 것처럼 머신의 등급에 따라 Default 값이 결정된다.

[편집] IBM JVM (1.5 기준)

Sun Hotspot JVM이 반드시 Command Line에서 JVM Option을 지정해주어야 하는 반면, IBM JVM에서는 다음과 같은 세 가지 방법으로 Option을 지정할 수 있다.

  • Command Line: java -Xgcpolicy:optthruput 과 같은 형태로 지정
  • Options File: –Xoptionsfile 옵션을 이용해서 Option을 모아둔 Text File을 지정. Optionsfile은 다음과 같은 형태이다.
#My options file
-X<option1>
-X<option2>=\<value1>,\
      <value2>
-D<sysprop1>=<value1>
  • IBM_JAVA_OPTIONS 환경변수: IBM_JAVA_OPTIONS 환경변수에 값을 지정(예: IBM_JAVA_OPTIONS=-X<option1> -X<option2>=<value1>)


[편집] Standard Options

Option Description
-memorycheck:<optiton> JVM 내부에서 발생하는 Memory Leak을 추적하기 위한 용도로 사용된다. JVM 기술지원 엔지니어들이 사용하는 용도로 보면 정확한다. JVM 자체는 OAK 로 구현되었다. 따라서 JVM 내부에서 발생하는 Memory Leak은 Java에서 발생하는 것과는 달리 진정한 의미에서는 Memory Leak으로 이해할 수 있다. 다음과 같은 옵션들이 제공된다(IBM JVM Diagnositics Guide에서 발췌)
  • all - The default if just -memorycheck is used. Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough and should cause the JVM to exit on nearly all memory-related problems very soon after they are caused. This option has the greatest impact on performance.
  • quick - Enables block padding only. Used to detect basic heap corruption. Pads every allocated block with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective.
  • nofree - Keeps a list of already used blocks instead of freeing memory. This list is checked, along with currently allocated blocks, for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is "dereferenced" after its target memory is freed). This option cannot be reliably used with long-running applications (such as WAS), because "freed" memory is never reused or released by the JVM.
  • failat=<number of allocations> - Causes memory allocation to fail (return NULL) after <number of allocations>. Setting <number of allocations> to 13 will cause the 14th allocation to return NULL. Deallocations are not counted. Use this option to ensure that JVM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit.
  • skipto=<number of allocations> - Causes the program to check only on allocations that occur after <number of allocations>. Deallocations are not counted. Used to speed up JVM startup when early allocations are not causing the memory problem. As a rough estimate, the JVM performs 250+ allocations during startup.
  • callsite=<number of allocations> - Prints callsite information every <number of allocations>. Deallocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include the number and size of allocation and free requests since the last report, and the number of the allocation request responsible for the largest allocation from each site. Callsites are presented as sourcefile:linenumber for C code and assembly function name for assembler code. Callsites that do not provide callsite information are accumulated into an "unknown" entry.
  • zero - Newly allocated blocks are set 0 instead of being filled with the 0xE7E7xxxxxxxxE7E7 pattern. Setting to 0 helps you to determine whether a callsite is expecting zeroed memory (in which case the allocation request should be followed by memset(pointer, 0, size)).
-showversion Java의 버전과 기본적인 사용법에 대한 정보를 제공한다.
-verbose:<option> Option에 따라 상세 정보를 출력한다. 다음과 같은 옵션이 제공된다.
  • class - Class Loading 정보를 Standard Err에 출력한다. 출력 예는 아래와 같다.
class load: java/io/FilePermission
class load: java/io/FilePermissionCollection
class load: java/security/AllPermission
...
class load: test
class load: test from: file:/C:/Documents/Java_Test/GC%20dump/
  • dynload - Class Loading에 대한 매우 상세한 정보를 제공한다. 클래스명, 클래스 크기, 로딩 시간등의 정보를 포함한다. 출력 예는 아래와 같다.
<  Class size 6594; ROM size 7056; debug size 0> 
<  Read time 128 usec; Load time 126 usec; Translate time 222 usec>
<Loaded java/security/BasicPermissionCollection from c:\IBM\WebSphere\AppServer\java\jre\lib\core.jar>
<  Class size 4143; ROM size 3264; debug size 0>
<  Read time 103 usec; Load time 81 usec; Translate time 117 usec>
<Loaded java/security/Principal from c:\IBM\WebSphere\AppServer\java\jre\lib\core.jar>
<  Class size 239; ROM size 248; debug size 0>
<  Read time 44 usec; Load time 23 usec; Translate time 20 usec>
<Loaded test>
<  Class size 370; ROM size 448; debug size 0>
<  Read time 0 usec; Load time 28 usec; Translate time 39 usec>
  • gc - GC 작업에 대한 정보를 제공한다. 자세한 내용은 GC Dump를 참조한다.
  • jni - JNI 호출에 대한 정보를 제공한다. 출력 예는 아래와 같다.
<JNI ReleaseStringChars: buffer=41EC45B8>
<JNI GetStaticMethodID: gc_dump.main ([Ljava/lang/String;)V>
<JNI GetMethodID: java/lang/reflect/Method.getModifiers ()I>
<JNI GetMethodID: java/lang/String.<init> ([B)V>
<JNI FindClass: java/lang/Object>
<JNI GetMethodID: java/lang/Object.finalize ()V>
<JNI FindClass: java/lang/ref/Reference>
<JNI GetMethodID: java/lang/ref/Reference.enqueueImpl ()Z>
  • sizes - Memory 사용과 관련된 설정값을 출력한다. 출력 예는 아래와 같다.
 -Xmca32K              RAM class segment increment
 -Xmco128K            ROM class segment increment
 -Xmns0K                initial new space size
 -Xmnx0K                maximum new space size
 -Xms4M                 initial memory size
 -Xmos4M               initial old space size
 -Xmox1047608K     maximum old space size
 -Xmx1047608K       memory maximum
 -Xmr16K               remembered set size
 -Xmso32K             OS thread stack size
 -Xiss2K                java thread stack initial size
 -Xssi16K              java thread stack increment
 -Xss256K             java thread stack maximum size
 -Xscmx16M          shared class cache size
  • stacks - Thread 별로 Java/C Stack의 사용 크기를 출력한다. 출력 예는 아래와 같다.
JVMVERB000I Verbose stack: "Thread-1" used 188/3756 bytes on Java/C stacks
JVMVERB000I Verbose stack: "Thread-2" used 516/3756 bytes on Java/C stacks
JVMVERB000I Verbose stack: "main" used 1368/0 bytes on Java/C stacks
JVMVERB000I Verbose stack: "Finalizer thread" used 456/2308 bytes on Java/C stacks
JVMVERB000I Verbose stack: "Gc Slave Thread" used 232/3060 bytes on Java/C stacks

[편집] Non-Standard Options

Option Default Description
-Xalwaysclassgc -Xclassgc 옵션에 의해 결정됨 Global Collection이 발생할 때 Class GC를 수행할 지의 여부를 지정한다. classgc 옵션과 동일한 값이며, Default는 True이다.
-Xbootclasspath Sun JVM의 bootclasspath 옵션과 동일
-Xcheck:jni False Sun JVM의 check:jni 옵션과 동일
-Xclassgc True Classloader가 변했을 때만 Class GC를 수행할 지의 여부를 결정한다.
-Xcodecache<size> OS/Hardware Architecture에 따라 결정됨
-Xcomp -Xjit:count=0 옵션을 사용한 것과 동일. z/OS에서만 사용되며, deprecated 옵션이다.
-Xcompactexplicitgc False System.gc() 호출에 의한 Explicit GC가 발생했을 경우 항상 Compaction을 수행할 지의 여부를 결정한다. Sun Hotspot JVM의 경우에는 System.gc() 호출이 발생할 경우 반드시 Full GC를 수행한다. 반면 IBM JVM의 경우에는 이전 GC 작업에서 Compaction이 발생하지 않은 경우에만 Compaction을 수행한다.
-Xcompactgc False System GCGlobal GC가 발생할 때마다 Compaction을 수행한다.
-Xconcurrentbackground 1 Response Time Collector에서 Concurrent Mark를 수행할 Background Thread의 개수를 지정한다. Concurrent Background Thread는 Application Thread의 성능을 다소 저하시킬 수 있으므로 하나만 구동하는 것이 바람직하다. 단, Concurrent Mark 작업이 잘 진행되지 않아 문제가 생기는 경우에는 이 값을 키우는 것이 해결책이 될 수 있다.
-Xconcurrentlevel<value>
-Xconmeter<option>
-Xdisableexcessivegc False GC 작업에 지나치게 많은(Excessive) 시간이 소요된 경우에 Out Of Memory Error를 유발하지 않도록 지정한다.
-Xdisableexplicitgc False System.gc() 호출에 의한 GC 작업을 비활성화한다. 이 옵션을 사용하면 System.gc()를 호출하더라도 GC 작업이 발생하지 않는다. RMI에 의한 불필요한 GC 작업이나 사용자의 실수에 의한 강제적인 GC 작업을 방지하고자 하는 목적으로 사용된다.
-Xdisablejavadump False Java Dump의 생성을 비활성화시킨다. IBM JVM은 치명적인 Error나 Signal을 받으면 Java Dump를 생성함으로써 사후 문제를 디버깅할 수 있도록 한다. 특정 문제로 인해 지나치게 많은 Dump가 생성될 때 이 옵션을 비활성시키는 경우가 있다.
-Xdisablestringconstantgc False Interned String에 대한 GC 작업을 비활성화한다.
-Xenableexcessivegc True GC 작업에 지나치게 많은(Excessive) 시간이 소요된 경우에 Out Of Memory Error를 유발하도록 지정한다. disableexcessivegc와 반대의 역할을 한다.
-Xenablestringconstantgc True Interned String에 대한 GC 작업을 활성화한다. disablestringconstantgc 옵션과 반대의 역할을 한다.
-Xgcpolicy<option> optthruput Garbage Collector의 종류를 결정한다.
  • optthruput: Throughput Collector를 사용한다. 처리량(Throughput)을 최적화할 목적으로 사용되며, Default Collector이다.
  • optavgpause: Response Time Collector를 사용한다. 응답시간(Response Time)을 최적화할 목적으로 사용된다. GC에 의한 Pause Time을 최소하기 위해 Concurrent Mark/Sweep 작업을 수행한다. Throughput Collector에 비해 처리량으로 다소(5~10%) 떨어진다.
  • gencon: Concurrent Generational Collector를 사용한다. IBM JDK 1.5에서 추가되었다. Sun Hotspot JVM의 CMS Collector와 거의 동일한 방식으로 동작하다.
  • subpool: Subpool Collector를 사용한다.
-Xgcthreads<value> CPU# Throughput Collector는 Mark & Sweep 작업을 Parallel하게, 즉 동시에 여러 Thread를 사용해서 수행한다. 이 옵션을 통해 Parallel GC를 수행할 Thread 수를 지정한다. 기본적으로 CPU 개수를 모두 활용한다. 만일 하나의 Machine에서 여러 JVM을 구동하거나, 다른 종류의 Application과 JVM이 공존하는 경우에는 이 값을 줄임으로써 Context Switching에 의한 성능 저하를 피할 수 있다.
gcworkpackets
int
iss
-Xjit:<options> True(JIT 컴파일을 사용함) JIT 컴파일 옵션을 결정한다. <options>가 지정되지 않으면 단순히 JIT 컴파일을 활성화한다. 이 옵션은 JIT 컴파일러의 버그로 인해 JVM 장애에 대해 Workaround로 많이 활용된다.

JIT 컴파일러의 버그에 의한 JVM Crash가 발생할 경우에는 다음과 같은 유형의 Error Stacktrace가 기록된다.

...
TR_GlobalRegisterAllocator::perform()
TR_OptimizerImpl::performOptimization()
TR_OptimizerImpl::performOptimization()
TR_OptimizerImpl::optimize()
...

이 경우에는 다음과 같은 옵션을 이용해서 JIT 컴파일을 제어할 수 있다.

# Inlining을 비활성화한다.
-Xjit:disableInlining
-Xjit:{java/lang/Math.max(II)I}(disableInlining)

# 특정 메소드를 Optimization에서 제외한다.
-Xjit:exclude={java/lang/Math.max(II)I} ...

아래 옵션들은 JIT 컴파일러에 문제가 발생한 경우 이를 좀 더 쉽제 추적하고자 할 때 사용된다.

count=<n>
   <n>번 째 수행에서 Method를 JIT 컴파일한다. JIT 문제를 추적할 때는 "0"의 값을 사용함으로써 보다 빨리 컴파일이 이루어지도록 한다.    
optlevel=[noOpt | cold | warm | hot | veryHot | scorching]
   [비최적화 ~ 최고 최적화]까지 JIT 컴파일에 의한 최적화 레벨을 지적한다.
verbose
   JIT 컴파일 과정에서 사용된 정보와 컴파일 과정을 출력한다.

아래에 -Xjit:verbose 옵션의 출력 예가 있다. count 값은 1000, optlevel 값은 warm이 기본값임을 알 수 있다.

JIT type: Testarossa (Full)
JIT options specified:
    verbose
options in effect:
    bcount=250
    catchSamplingSizeThreshold=1100
    classLoadPhaseInterval=500
    classLoadPhaseThreshold=155
    code=512 (KB)
    codepad=0 (KB)
    codetotal=0 (KB)
    count=1000
    ...
    stack=256
    target=ia32-win32
    verbose=1
 
+ (warm) java/lang/Double.doubleToRawLongBits(D)J @ 0x41630014-0x41630030
+ (warm) java/lang/System.getEncoding(I)Ljava/lang/String; @ 0x41630054-0x41630145
+ (warm) java/lang/String.hashCode()I @ 0x4163017C-0x4163024A
+ (warm) java/util/HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; @ 0x4163027C-0x416304AF
+ (warm) java/util/Locale.toLowerCase(Ljava/lang/String;)Ljava/lang/String; @ 0x416304DC-0x416307FF
...
+ (warm) java/io/FileOutputStream.writeBytes([BIILjava/io/FileDescriptor;)V @ 0x41636C34-0x41636D45|-
loainitial
loamaximum
loaminimum
lp
maxe
maxf
maxt
mca
mco
mine
minf
mint
mn
mns
mnx
mo
moi
mos
mox
mr
mrx
ms
mso
mx
noaot
noclassgc
nocompactexplicitgc
nocompactgc
-Xnojit False JIT 컴파일 옵션을 사용하지 않는다.
noloa
nopartialcompactgc
nosigcatch
nosigchain
optionsfile
oss
partialcompactgc
quickstart
realtime
rs
runhprof
samplingExpirationTime
scmx
shareclasses
sigcatch
sigchain
softrefthreshold<number>
ss
ssi
thr
verbosegclog:<file>
2009/12/09 14:16 2009/12/09 14:16
이 글에는 트랙백을 보낼 수 없습니다

JSP & PHP with EASE

by Ahmad Baitalmal
published on: 07/05/2006


Inter-mingling JSP and PHP code inside EASE is extremely simple. You can use JSP/PHP code inside your EASE script to leverage any existing code you might already have or extent the platform with third party libraries and capabilities.

The Etelos Application Server platform allows you to drop in and out of PHP/JSP code seamlessly. Below is an example of how you can access any EAS binder variable.

< #[SYSTEM.DATE_TIME]#> <
br>
<?php
print eas_get_value( "system.date_time" ) ."<br>";
?>

<?jsp

<%= eas_get_value("system.date_time") "<br/>"%>

?>



The three lines in the code above will produce identical output. You have full un-crippled access to PHP & JSP. You can interact with EAS data in real-time and see your changes on the fly. The following code creates a new binder tag in PHP  and prints it out in EASE.

<?php
print eas_set_value( "my.data", "right here" );
?>

My data is <b></b><br>

As expected, the output is:

My data is right here

Or in JSP:
<?jsp
<% eas_set_value( "my.data", "right here" )%>
?>

My data is <b>< #[MY.DATA]#></b><br>

EASE skips much of the grunt work usually required in web development. With the PHP/JSP interfaces, you can still do all the fine-grained coding that you may need. For example, you may need to update a few binder instances real quick without user interaction. While eas_set_value and eas_get_value give you access to the EAS tag data in real-time, after the page execution is done, your changes aren't saved to the database. Here is how you modify the actual data in contacts and instances in PHP:

<?php
eas_set_instance_value( "products.6", "color", "Tomato");
eas_set_contact_value( eas_get_value("contact.id"), "age", "33");
?>

< # apply instance products.6 and reference as "product". # >
The product color is < #[product.color]# >
<br>

The instance's color variable is changed in the database to "Tomato" and the < # [contact.id] # >'s age variable is changed to "33". In the opposite direction, you can load an instance or contact from the database like this:

<?php
print_r( eas_get_instance( "products.6" ) );
print_r( eas_get_contact( eas_get_value("contact.id") ) );
?>


This code will print two arrays. The first array is an associative array of variable=>value for instance id 6 from the products binder. The next array is also an associative array of variable=>value for the < # [contact.id] # >.

The following code goes a little bit further. eas_query enables you to write your own SQL queries to the database.
<?php
$result = eas_query( "select * from binder_12 where lower( color ) != 'red';" );
if( $result->ok )
{
    print "<u>". $result->count ."</u> products were found\n";    
    print "<u>". $result->updated ."</u> products were updated\n";    
    while( $product = pg_fetch_assoc($result->recordset) )
    {
        print "<b>". $product['instance_id'] . " - " . $product['name'] . "</b>\n";
        print $product['color'] ."\n";
        print $product['description'] ."\n\n";
    }
}
?>


In this example, a query is issued to return all products (binder_12) where the color is not red. The result object that is returned provides a few useful properties.

$result->ok is true when the query is executed successfully, otherwise it's false. $result->count has the number of rows returned, and $result->updated has the number of rows that were updated if the query was an UPDATE.



Here is the same code in JSP:
<?jsp

<%
   try
   {
       ResultSet rs = eas_query( "select * from binder_12;" );
       Statement st = rs.getStatement();
             rs.last();
       int count = rs.getRow();
       rs.beforeFirst();
             int updateCount = st.getUpdateCount();
%>
       <%="<u>" count "</u> products were found<br/>"%>
       <%="<u>" updateCount "</u> products were updated<br/>"%>
<%
       while( rs.next() )
       {
%>
           <%="<b>" rs.getString( "instance_id" ) "-" rs.getString( "name" )
               "</b><br/>"%>
           <%=rs.getString( "color" ) "<br/>"%>
           <%=rs.getString( "description" ) "<br/><br/>"%>
<%
       }          st.close();
   }
   catch( Exception e ) {}
%>

?>


You can easily imagine doing some more advanced queries that would be hard or inefficient to do in the standard list engine like unions or intersects. Having the full power and flexibility of PHP and JSP is also a big plus, you have the speed of rapid web application development with EASE and the flexibility and extensibility of PHP and JSP all in a single page.




//  This following example is not featured int he magazine because of space in the printed edition.  Here is an extra example of setting contact values in JSP.

<?jsp
<%@ page import="java.util.*" %>

<%=eas_set_contact_value( "2330c69b9fab0cfe170fad0a95e8f7f8", "last_name", "Changed!" )%>

<%
   Map m = eas_get_contact( "2330c69b9fab0cfe170fad0a95e8f7f8" );
   Iterator i = m.keySet().iterator();
   String result = "";
   while( i.hasNext() )
   {
       Object key = i.next();
       Object val  = m.get( key );
             result = key.toString() ":" val.toString() "<br/>";
   }
%>

<%="<br/><br/>result:<br/>" result%>

?>


Relevent Tags: EASE tips   PHP Dev   JSP Dev   

2009/11/10 11:51 2009/11/10 11:51
이 글에는 트랙백을 보낼 수 없습니다

ESftp 라는게 Eclipse와 연동되는 FTP plug in으로 유용한 기능을 지니고 있었으나

Eclipse 3.2로 업그레이드 되면서 실행이 되지 않았습니다.

그러나 드디어 200711월 말 패치로 3.2버전에서도 실행이 가능하군요.


먼저 첨부한 jar 파일을 Eclipse 폴더의 plugin 폴더에 복사해서 넣으시면 메뉴가
생깁니다.


연결하고자 하는 프로젝트를 선택하여 우 클릭하여
 Properties를 선택하면 ESftp라는 메뉴가 생겼습니다.


선택하시면
간단한 메뉴가 나옵니다.


Protocol
FTP로 설정 Test settings을 하면 Eclipse가 뻗어버리는


현상이 생기므로 ProtocalSFTP 바꿔주시는게 좋습니다.


그리고 프로젝트 하위와 FTP root가 일치한다면 Site Root 옵션에 ‘/’하나 써주시면 되겠습니다.


그리고 Test settings를 클릭하면
이렇게 성공했다는 메시지가 나타나면 성공입니다.


.java
파일의 경우 컴파일된 클래스를 우클릭하면 위와 같은 메뉴를 통해 서버에 전송할 수 있고


보시는 바와 같이 단축키는 Ctrl+Alt+P 입니다.


전송을 실행하면


Eclipse Console
에 메시지가 뜨면 전송이 잘된 것 입니다.


확인해 보세요.


이제 Eclipse로 클래스파일 작업 후 타 FTP 프로그램이나 Application을 사용하는


불편함이 줄어들겠죠.


그럼 도움이 되시길 바랍니다.

 

2009/03/13 14:49 2009/03/13 14:49
이 글에는 트랙백을 보낼 수 없습니다
이클립스를 위주로 개발을 하지만 아직도 가끔 에딧플러스를 이용하는데요.
 
제경우 가장큰 이유중 하나가 이클립스에서 자동 줄바꿈이 되지않아서 입니다.
 
html같은 부분을 편집할때보면 가로로 줄이 긴경우 무척이나 불편하더군요
 
오늘 작정하고 구글검색을 해서 찾아봤습니다.
이곳인데요.
영어가 짧아서 정확히 무슨소리인지는 알수없지만 아직 버그가 좀 있다고 하는말
같아요 -_-;;
 
설치 방법은 나와 있는 방법그대로 하시면 됩니다.
 

How to install?

  1. Open Eclipse
  2. Help > Software Updates > Find and Install
  3. Search for New Features to Install
  4. New Remote Site
  5. Enter the url - http://ahtik.com/eclipse-update/
  6. Install and Enjoy
위순서대로 하신후에 이클립스를 재시작합니다
그리고 문서를 하나 열어봅니다
 
 
 
 
위소스는 네이버 메인화면 소스입니다. 보시는 바와 같이 가로 스크롤이 길게 생겨있네요.
문서에 대고 오른쪽 클릭을 하면 virtual Word Wrap 이란메뉴가 있습니다.
이메뉴를 클릭해주시면 됩니다
 
 
 
보시는 바와 같이 가로 스크롤이 없어졌네요^^
같은 한줄로 되어있던부분은 같은 백그라운드 칼라로 하이라이트 되어있습니다.~
 
오늘 오후에 설치를 해보았기 때문에 현재까진 특별한 버그는 발견하지 못했습니다.
그리고 문제시 삭제하는 방법은
 
 
Help > Software Updates > Manage Configuration 선택
WordWrap Feature 를 disable시킨담에 uninstall하시면 됩니다~


BR />
Flex Builder3 에서도 됩니다 ㅎㅎ
2009/03/13 14:40 2009/03/13 14:40
이 글에는 트랙백을 보낼 수 없습니다
LINUX
# getconf LONG_BIT


HP UX

11.xx 일 경우
# getconf KERNEL_BITS
64

10.xx 일 경우
# getconf LONG_MAX
2147483647
(64비트임)로 확인할 수 있습니다

AIX

현재 load된 kernel 이 32-bit 혹은 64-bit 인지 확인하는 명령어
# bootinfo -K
32

사용중인 machine이 32-bit 혹은 64-bit 인지 확인하는 명령어
# bootinfo -y
32


SOLARIS

# isainfo -kv
64-bit sparcv9 kernel modules
현재 이 시스템은 64bit 커널을 가지고 운영을 하는 시스템 이다.

# isainfo -kv
32-bit sparcv kernel modules
이 시스템은 32bit 커널을 가지고 운영을 하는 시스템이다.

# isainfo -v
64-bit sparcv9 applications 32-bit sparc applications
"-v"만 했을 경우 이 시스템에서는 32bit / 64bit 체계의 프로그램을 사용할 수 있다.

# isainfo -v
32-bit sparc applications
이 시스템은 32bit 체계의 프로그램만 구성하여 사용할 수 있다.
2009/02/25 11:29 2009/02/25 11:29
이 글에는 트랙백을 보낼 수 없습니다

명령행 인수

Eclipse 런타임의 다양한 부분에서 처리하는 명령행 인수가 아래에 나열됩니다. -D VM 인수를 사용하는 명령행에서 시스템 특성을 사용하거나 config.ini 파일에서 값을 지정하여 이러한 값 대부분을 지정할 수도 있습니다. 후자의 방법을 사용하면 명령행 인수를 사용하지 않고 Eclipse를 사용자 정의할 수 있습니다.

목록의 각 인수에서 해당 시스템 특성 키를 {}로 묶어 지정합니다. 또한 ()로 묶인 명령행 인수를 처리할 Eclipse 런타임 계층도 지정됩니다. 이 방법은 런타임 부분을 특수한 요구에 맞게 바꾸는 사용자에게 유용합니다.

-application <id> (Runtime)
eclipse.application을 <id>로 설정하는 것과 동등함
-arch <architecture> (OSGi)
osgi.arch를 <architecture>로 설정하는 것과 동등함
-clean (OSGi) NEW
osgi.clean을 "true"로 설정하는 것과 동등함
-configuration <location> (Main)
osgi.configuration.area를 <location>으로 설정하는 것과 동등함
-console [port] (OSGi) NEW
osgi.console을 [port] 또는 기본 포트를 사용할 경우(즉, 포트가 지정되지 않은 경우) 빈 문자열로 설정하는 것과 동등함
-consoleLog (Runtime)
eclispe.consoleLog를 "true"로 설정하는 것과 동등함
-data <location> (OSGi)
osgi.instance.area를 <location>으로 설정하는 것과 동등함
-debug [options file] (OSGi)
osgi.debug를 [options file] 또는 예를 들어 옵션 파일 위치를 지정하지 않은 경우 간단히 디버그를 사용할 수 있도록 빈 문자열로 설정하는 것과 동등함
-dev [entries] (OSGi)
osgi.dev를 [entries] 또는 예를 들어 항목을 지정하지 않은 경우 간단히 dev 모드를 사용할 수 있도록 빈 문자열로 설정하는 것과 동등함
-endSplash <command> (Main)
스플래시 화면을 아래로 내릴 때 사용할 명령을 지정합니다. 보통 Eclipse 실행 파일에서 제공합니다.
-feature <feature id> (Runtime)
eclipse.product를 <feature id>로 설정하는 것과 동등함
-framework <location> (Main) NEW
osgi.framework를 <location>으로 설정하는 것과 동등함
-initialize (Main)
실행 중인 구성을 초기화합니다. 모든 런타임 관련 데이터 구조 및 캐시를 새로 고칩니다. 모든 사용자/플러그인의 정의된 구성 데이터가 제거되지 않습니다. 모든 응용프로그램이 실행되지 않고 모든 제품 스펙이 무시되며 UI가 표시되지 않습니다. 예를 들어 스플래시 화면이 그려지지 않습니다.
-install <location> (Main)
osgi.install.area를 <location>으로 설정하는 것과 동등함
-keyring <location> (Runtime)
디스크에서 권한 데이터베이스의 위치입니다. 이 인수는 -password 인수와 함께 사용해야 합니다.
-nl <locale> (OSGi)
osgi.nl을 <locale>로 설정하는 것과 동등함
-noLazyRegistryCacheLoading (Runtime)
eclipse.noLazyRegistryCacheLoading을 "true"로 설정하는 것과 동등함
-noRegistryCache (Runtime)
eclipse.noRegistryCache를 "true"로 설정하는 것과 동등함
-noSplash (Executable, Main)
스플래시 화면의 표시 여부를 제어합니다.
-os <operating system> (OSGi)
osgi.os를 <operating system>으로 설정하는 것과 동등함
-password <password> (Runtime)
권한 데이터베이스의 암호
-pluginCustomization <location> (Runtime)
eclipse.pluginCustomization을 <location>으로 설정하는 것과 동등함
-product <id> (OSGi) NEW
eclipse.product를 <id>로 설정하는 것과 동등함
-showSplash <command> (Main)
스플래시 화면을 표시할 때 사용할 명령을 지정합니다. 보통 Eclipse 실행 파일에서 제공합니다.
-user <location> (OSGi) NEW
osgi.user.area를 <location>으로 설정하는 것과 동등함
-vm <path to java executable> (Executable, Main) NEW
Eclipse 실행 파일에 전달하는 경우 이 옵션은 Eclipse 실행에 사용할 Java VM 위치를 찾는 데 사용됩니다. 이 때 찾는 위치는 해당 Java 실행 파일의 전체 파일 시스템 경로여야 합니다. 경로를 지정하지 않으면 Eclipse 실행 파일은 검색 알고리즘을 사용하여 적절한 VM을 찾습니다. 모든 경우 실행 파일은 -vm 인수를 사용하여 Java 기본에 사용된 실제 VM의 경로를 전달합니다. 그 다음 Java 기본은 이 값을 eclipse.vm에 저장합니다.
-vmargs [vmargs*] (Executable, Main) NEW
Eclipse에 전달하는 경우 이 옵션은 Eclipse 실행에 사용할 Java VM 조작 위치를 찾는 데 사용됩니다. 위치를 지정하는 경우 이 옵션은 명령행의 끝에 와야 합니다. 위치를 실행 파일 명령행에 지정하지 않는 경우에도 실행 파일은 -vmargs 인수를 사용하는 Java로 전달된 명령행에 실행 중인 클래스를 포함한 관련 인수를 자동으로 추가합니다. 그 다음 Java 기본은 이 값을 eclipse.vmargs에 저장합니다.
-ws <window system> (OSGi)
osgi.ws를 <window system>으로 설정하는 것과 동등함

더 이상 사용하지 않는 명령행 인수

다음 명령행 인수는 더 이상 관련이 없거나 대체된 상태이고 역방향 호환성을 유지보수하도록 런타임에서 이용되며 실행 중인 응용프로그램에 전달되지 않습니다.

-boot
-configuration 참조
-classLoaderProperties
더 이상 관련 없음
-firstUse
더 이상 관련 없음
-newUpdates
더 이상 관련 없음
-noPackagePrefixes
더 이상 관련 없음
-noUpdate
더 이상 관련 없음
-plugins
더 이상 관련 없음
-update
더 이상 관련 없음

기타

다음 명령행 인수는 다양한 Eclipse 플러그인에서 정의되며 정의하는 플러그인이 설치, 해석 및 활성화된 경우에만 지원됩니다.

-noVersionCheck (workbench)
<description>
-perspective (workbench)
<description>
-refresh (org.eclipse.core.resources)
<description>
-showLocation (org.eclipse.ui.ide.workbench)
<description>
-allowDeadlock
<description>

시스템 특성

다음 시스템 특성은 Eclipse 런타임에서 사용됩니다. "osgi"로 시작하는 이러한 시스템 특성은 OSGi 프레임워크 구현에 특정하지만 "eclipse"로 시작하는 일부 시스템 특성은 OSGi 프레임워크의 맨 위에 계층화된 Eclipse 런타임에 특정함에 유의하십시오.

이러한 특성 대부분은 명령행과 동등합니다({} 중괄호의 값 및 명령행 인수 섹션 참조). 사용자는 명령행 또는 특성 설정을 사용하여 값을 지정할 수 있습니다. 특성은 다음과 같은 방법으로 설정될 수 있습니다.

  • -DpropName=propValue를 Java VM의 VM 인수로 사용
  • 해당 구성 영역에서 config.ini 파일에 필요한 특성 설정
eclipse.application {-application}
실행할 응용프로그램 ID입니다. 여기에 지정된 값은 실행 중인 제품(eclipse.product 참조)에서 정의한 응용프로그램을 대체합니다.
eclipse.commands
sdf
eclipse.consoleLog
"true"인 경우 로그 출력도 Java의 System.out에 송신됩니다. 보통 명령 쉘에 다시 송신됩니다. -debug와 함께 결합하면 유용합니다.
eclipse.debug.startupTime
이 세션에서 Java VM이 시작된 시간(밀리 초)
eclipse.exitcode
<description>
eclipse.exitdata
<description>
eclipse.manifestConverter
레거시 plugin.xml 파일을 manifest.mf 파일로 변환할 때 사용할 manifest 변환기의 클래스 이름
eclipse.noExtensionMunging
"true"인 경우 레거시 레지스트리 확장은 그대로 남아 있습니다. 기본적으로 이러한 확장은 갱신하여 Eclipse 3.0에 있는 새 확장점 ID를 사용합니다.
eclipse.noLazyRegistryCacheLoading {-noLazyRegistryCacheLoading}
"true"인 경우 플랫폼의 플러그인 레지스트리 캐시 로드 최적화가 비활성화됩니다. 기본적으로 구성 요소는 레지스트리 캐시가 사용 가능한 경우 요청할 때에만 해당 레지스트리 캐시에서 로드되어 메모리 예정 범위를 줄입니다. 이 옵션은 시작할 때 레지스트리 캐시를 전체적으로 로드하도록 강제 실행합니다.
eclipse.noRegistryCache {-noRegistryCache}
"true"인 경우 내부 확장 레지스트리 캐시의 읽기 및 쓰기가 불가능합니다.
eclipse.pluginCustomization {-pluginCustomization}
플러그인 환경 설정의 기본 설정이 들어 있는 특성 파일의 파일 시스템 위치입니다. 이 기본 설정은 1차 기능에 지정된 기본 설정을 대체합니다. 상대 경로는 Eclipse 자체의 현재 작업 디렉토리에 따라 해석됩니다.
eclipse.product {-product}
실행 중인 제품 ID입니다. 이 ID를 통해 다양한 브랜딩 정보 및 사용되는 응용프로그램을 제어합니다.
eclipse.vm {-vm}
Eclipse 실행에 사용한 Java 실행 파일의 경로입니다. 이 정보는 재실행 명령행을 구성하는 데 사용됩니다.
eclipse.vmargs {-vmargs}
Eclipse 실행에 사용한 VM 인수를 나열합니다. 이 정보는 재실행 명령행을 구성하는 데 사용됩니다.
osgi.adaptor
사용할 OSGi 프레임워크 어댑터의 클래스 이름
osgi.arch {-arch}
-arch 참조
osgi.baseConfiguration.area
asf
osgi.bundles
시스템을 가동하여 실행하면 자동으로 설치되어 선택적으로 시작되는 쉼표로 구분된 번들 목록입니다. 다음은 각 항목 양식입니다.
    <URL | simple bundle location>[@ [<start-level>] [":start"]]
시 작 레벨(>0인 정수)이 누락되면 프레임워크에서는 번들의 기본 시작 레벨을 사용합니다. "start" 태그를 추가하면 번들은 설치 후 시작됨으로 표시됩니다. 단순 번들 위치는 프레임워크의 상위 디렉토리에 상대적으로 해석됩니다. 시작 레벨은 번들을 실행해야 하는 경우에 OSGi 시작 레벨을 표시합니다. 이 값이 설정되지 않으면 시스템에서 적절한 기본값을 계산합니다.
osgi.clean
"true"로 설정하면 OSGi 프레임워크 및 Eclipse 런타임에 사용되는 캐시된 데이터가 정리됩니다. 그러면 번들 종속성 분석 및 eclipse 확장 레지스트리 데이터를 저장하기 위해 사용되는 캐시가 정리됩니다. 이 옵션을 사용하면 eclipse는 이 캐시들을 다시 초기화하게 됩니다.
osgi.configuration.cascaded
"true"로 설정하면 이 구성은 상위 구성에 계단식으로 설정됩니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.configuration.area {-configuration}
이러한 플랫폼을 실행하는 데 사용할 구성 위치입니다. 구성에서는 실행한 플러그인 및 다양한 기타 시스템 설정을 판별합니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.configuration.area.default
이러한 플랫폼을 실행하는 데 사용할 기본 구성 위치입니다. 구성에서는 실행한 플러그인 및 다양한 기타 시스템 설정을 판별합니다. 이 값, 즉 기본 설정은 osgi.configuration.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.console {-console}
널이 아닌 값으로 설정하면 OSGi 콘솔을 설치한 경우 해당 콘솔이 사용 가능합니다. 값이 적절한 정수인 경우 이 값은 콘솔이 청취하는 포트로 해석되어 지정된 포트로 해당 출력을 지정합니다. 시스템 상태를 조사할 때 유용합니다.
osgi.console.class
요청할 경우 실행할 콘솔의 클래스 이름
osgi.debug {-debug}
널이 아닌 값으로 설정하면 플랫폼은 디버그 모드가 됩니다. 값이 문자열인 경우 이 값은 .options 파일 위치로 해석됩니다. 이 파일은 플러그인에서 사용 가능한 디버그 확장점 및 이러한 확장점의 사용 가능 여부를 표시합니다. 위치를 지정되지 않은 경우 플랫폼에서는 설치 디렉토리 아래의 .options 파일을 검색합니다.
osgi.dev {-dev}
빈 문자열로 설정하면 dev 모드가 간단히 켜집니다. 또한 이 특성은 플러그인 세트의 사용자 정의 클래스 경로 추가가 들어 있는 Java 특성 파일의 URL 또는 각 플러그인의 클래스 경로에 추가되는 쉼표로 구분된 클래스 항목에 설정됩니다. 사용자 정의된 dev 시간 클래스 경로를 요구하는 각 플러그인의 경우 해당 파일에 다음 양식의 항목이 들어 있습니다.
    <plug-in id>=<추가할 쉼표로 구분된 클래스 경로 항목>
여기서 plug-in id "*"는 별도의 언급이 없는 한 모든 플러그인과 일치합니다.
osgi.framework
OSGi 프레임워크 URL 위치입니다. Eclipse 설치를 해체할 경우 유용합니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.frameworkClassPath
OSGi 프레임워크 구현에 사용할 쉼표로 구분된 클래스 경로 항목 목록입니다. 상대 위치는 프레임워크 위치에 따라 해석됩니다(osgi.framework 참조).
osgi.install.area {-install}
플랫폼의 설치 위치입니다. 이 설정은 기본 Eclipse 플러그인의 위치를 표시하며 Eclipse 설치를 해체할 경우 유용합니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.instance.area {-data}
이 세션에서의 인스턴스 데이터 위치입니다. 플러그인에서는 이 위치를 사용하여 데이터를 저장합니다. 예를 들어 자원 플러그인에서는 이 위치를 프로젝트(작업공간이라고도 함)의 기본 위치로 사용합니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.instance.area.default
이 세션에서의 기본 인스턴스 데이터 위치입니다. 플러그인에서는 이 위치를 사용하여 데이터를 저장합니다. 예를 들어 자원 플러그인에서는 이 위치를 프로젝트(작업공간이라고도 함)의 기본 위치로 사용합니다. 이 값, 즉 기본 설정은 osgi.instance.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.manifest.cache
생성된 Manifest가 발견 및 생성된 위치입니다. 기본값은 구성 영역이지만 Manifest 캐시를 별도로 저장할 수 있습니다.
osgi.nl {-nl}
Eclipse 플랫폼을 실행할 로케일 이름입니다. NL 값은 표준 Java 로케일 이름 지정 규칙을 따라야 합니다.
osgi.os {-os}
운영 체제 값입니다. 이 값은 Eclipse에 알려진 Eclipse 프로세서 아키텍처 이름 중 하나여야 합니다(예: x86, sparc, ...).
osgi.splashLocation
Eclipse를 시작할 때 표시할 스플래시 화면(.bmp 파일)의 절대 URL 위치입니다. 이 특성은 osgi.splashPath에 설정된 값을 대체합니다.
osgi.splashPath
splash.bmp 파일을 검색하는 쉼표로 구분된 URL 목록입니다. 이 특성은 osgi.splashLocation에 설정된 값으로 대체됩니다.
osgi.user.area {-user}
사용자 영역의 위치입니다. 사용자 영역은 OS 사용자에게 특정한 데이터(예: 환경 설정)를 포함하고 Eclipse 설치, 구성 또는 인스턴스와는 독립되어 있습니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.user.area.default
사용자 영역의 기본 위치입니다. 사용자 영역은 OS 사용자에게 특정한 데이터(예: 환경 설정)를 포함하고 Eclipse 설치, 구성 또는 인스턴스와는 독립되어 있습니다. 이 값, 즉 기본 설정은 osgi.user.area에 설정된 값이 없는 경우에만 사용됩니다. 자세한 내용은 위치 섹션을 참조하십시오.
osgi.ws {-ws}
창 시스템 값입니다. 이 값은 Eclipse에 알려진 Eclipse 창 시스템 이름 중 하나여야 합니다(예: win32, motif, ...).
osgi.syspath
<xxx가 계속 사용됩니다. 이름을 고정합니다.>

위치

Eclipse 런타임에서는 플러그인 개발자에게 데이터를 읽거나 저장하는 컨텍스트를, Eclipse 사용자에게 데이터 공유 및 가시성의 범위에 대한 제어를 제공하는 위치 수를 정의합니다. Eclipse는 다음과 같이 위치 개념을 정의합니다.

User (-user) {osgi.user.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]
사용자 위치는 사용자에게 특정된 위치입니다. 보통 사용자 위치는 Java user.home 시스템 특성의 값에 기초하지만 해당 위치를 대체할 수 있습니다. 사용자 범위의 환경 설정과 같은 정보 및 로그인 정보는 사용자 위치에서 찾을 수 있습니다.
Install (-install) {osgi.install.area} [@user.home, @user.dir, filepath, url]
설치 위치는 Eclipse 자체가 설치된 위치입니다. 실제로 이 위치는 실행 중인 startup.jar 또는 eclipse.exe의 상위 디렉토리(보통 "eclipse")입니다. 여러 사용자가 설치를 공유할 수 있으므로 이 위치는 일반 사용자에게 읽기 전용으로 간주됩니다. 설치 위치를 설정하고 나머지 Eclipse에서 startup.jar를 분리할 수 있습니다.
Configuration (-configuration) {osgi.configuration.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]
구성 위치에는 실행할 설치 세트(또는 서브세트)를 식별 및 관리하는 파일이 들어 있습니다. 이와 같이 한 설치에 여러 구성이 있을 수 있습니다. 설치는 기본 구성 영역과 함께 제공될 수 있지만 일반 시작 시나리오는 쓰기 가능한 구성 위치를 더 찾으려는 런타임과 연관되어 있습니다.
Instance (-data) {osgi.instance.area} [@none, @noDefault, @user.home, @user.dir, filepath, url]
인스턴스 위치에는 사용자 정의 데이터 아티팩트가 들어 있습니다. 예를 들어 자원 플러그인에서는 인스턴스 영역을 작업공간 위치로 사용하므로 프로젝트의 기본 홈을 사용합니다. 기타 플러그인에서는 이 위치에서 필요한 모든 파일을 쓸 수 있습니다.

사용자는 이러한 모든 위치를 설정할 수 있지만 Eclipse에서는 값이 지정되지 않으면 올바른 기본값을 계산합니다. 위치를 설정하는 가장 일반적인 사용 케이스는 인스턴스 영역 또는 IDE 컨텍스트의 경우 작업공간입니다. 다음을 지정하여 특정 데이터 세트에서 기본 Eclipse 구성을 실행할 수 있습니다.

    eclipse -data c:\mydata

세부사항

위치는 URL입니다. 위치를 단순하게 표시하도록 파일 경로도 허용되고 자동으로 file: URL 형식으로 변환됩니다. 효율적인 제어 및 편의를 제공하는 사용 가능한 여러 사전 정의된 기호 위치도 있습니다. 위치 유형 및 기호 값을 조합한 모든 경우가 올바르지는 않음에 유의하십시오. 아래의 테이블에서는 가능한 조합을 자세히 표시합니다. 기본 케이스가 모든 위치에서 올바르고 쓰기 가능한 조합으로 설정되었으므로 일부 플러그인은 가능한 경우로 나열되었어도 다른 설정에서 실패할 수 있습니다. 예를 들어 인스턴스 영역을 정의하지 않으면 사용자 데이터에 초점을 맞춘 플러그인(예: Eclipse 자원 플러그인)에서 많은 작업을 수행할 수는 없습니다. 플러그인 개발자가 필요한 경우 지원한 설정을 선택하고 해당 기능을 설계해야 합니다.

@none
해당 위치를 명시적으로 설정하거나 기본값으로 설정할 수 없음을 표시합니다. 예를 들어 사용자 데이터가 없는 RCP 스타일 응용프로그램에서는 osgi.instance.area=@none을 사용하여 외부 파일이 디스크에 작성되지 않도록 할 수 있습니다. @none 뒤에 추가 경로 세그먼트가 올 수 없습니다.
@noDefault
정의되지 않거나 명시적으로 정의된 위치를 강제 실행합니다. 즉, Eclipse에서는 기본값을 자동으로 계산하지 않습니다. 이 방법은 해당 위치에 있는 데이터는 허용하려고 할 때 Eclipse 기본값이 적절하지 않은 경우 유용합니다. @noDefault 뒤에 추가 경로 세그먼트가 올 수 없습니다.
@user.home
Eclipse를 사용자 홈 디렉토리와 관련된 위치 값을 계산하도록 지정합니다. @user.home 뒤에 추가 경로 세그먼트가 올 수 없습니다. 모든 경우 "@user.home" 문자열이 Java "user.home" 시스템 특성 값으로 간단히 바뀝니다. 예를 들어 다음과 같이 설정합니다.
osgi.instance.area=@user.home/myWorkspace
다음은 이 때의 결과 값입니다.
file:/users/bob/myWorkspace
@user.dir
Eclipse를 현재 작업 디렉토리와 관련된 위치 값을 계산하도록 지정합니다. @user.dir 뒤에 추가 경로 세그먼트가 올 수 없습니다. 모든 경우 "@user.dir" 문자열이 Java "user.dir" 시스템 특성 값으로 간단히 바뀝니다. 예를 들어 다음과 같이 설정합니다.
osgi.instance.area=@user.dir/myWorkspace
다음은 이 때의 결과 값입니다.
file:/usr/share/eclipse/myWorkspace
위치/값
기본값 지원
파일/URL
@none
@noDefault
@user.home
@user.dir
인스턴스
예(기본값)
구성
예*
예*
설치
아니오
아니오
아니오
사용자

*는 이 설정이 기술적으로는 가능하지만 실용적으로는 관리에 어려움이 있음을 표시합니다. 특히 구성 위치가 없는 경우 Eclipse 런타임은 OSGi 프레임워크를 시작하는 경우에만 가져올 수 있습니다.

2009/02/24 12:21 2009/02/24 12:21
이 글에는 트랙백을 보낼 수 없습니다

작업을 하다 자바소스를 잃어버려 이전에 컴파일 해놓은 .class 파일을 역컴파일 해서 소스를

보고 싶을때가 있을것이다. 그리고 배포된 API 들을 열어 좋은 예가 되는 소스를 보고 공부해

볼수도 있다. 이럴때 eclipse 에서 볼수있는 방법이다.

환경은 Eclipse SDK 3.3 이며 jad 실행파일과 jadclipse 이클립스 플러그인이 필요하다.

Jad 다운로드 : http://www.kpdus.com/jad.html  jadnt158.zip

각종 OS 환경에 맞는 프로그램이 있는데 windows 용을 받는다.


Jadclipse다운로드: http://sourceforge.net/projects/jadclipse 에서

JadClipse (net.sf.jadclipse_3.3.0.jar) 를 다운 받는다. 다운받는 사이트에 보시면 eclipse 버전에 맞는 플러그인 버전이 표시 되어있으므로 맞는걸 다운받으면 된다.


먼저 jad.exe 를 사용해서 독립적으로 사용하는 방법과 eclipse 와 연동해서 사용하는 방법 두가지를

기술하도록 하겠다.

몇 개안되는 클래스파일들은 jad.exe 만으로 컴파일 하게 되면 더 편할수도 있는데 위에서 받은

jadnt158.zip 압축을 풀게 되면 jad.exe 가 나오게 되는데 이것을 java path 환경설정이 잡혀있는

bin 폴더에 넣는다. 도스창에서 실행을 바로 할수 있도록 하기 위함 이다.

제대로 깔렸는지 실행해본다.


아래 보는 바와 같이 programDlg.class 를 디컴파일 하게 되는데

명령어는 jad s .java [컴파일된파일명]로 넣어서 실행하면되는데 output[파일명].java가 될것이다.

하나의 컴파일된 클래스 파일이 아닌 폴더에 있는 모든 클래스 파일을 디컴파일하고 싶을 때

명령어는 다음과 같다. Jad -o -r -s .java **/*.class

다음은 이클립스에서 실행하기 위한 환경설정과 방법이다.

위에서 다운받은 jadclipse -> net.sf.jadclipse_3.3.0.jar eclipse plugin 폴더에 넣는다.

Windows > Preferences > java > Jadclipse 라는 메뉴가 생겼을 것이다.

기본셋팅은 아래와 같을텐데 그대로 둔다

다음 해야될것이 .class 파일클릭시 기본적으로 jadclipse 가 실행되도록 설정해줘야한다.

Windows> Preferences > General > Editors > File Associations 클릭하게 되면

모든 확장가가 기본적으로 취하게 되는 프로그램명들을 설정할수 있게 되어있는데 .class 파일을

클릭해서 아래에 jadclipse file view를 기본으로 사용하겠다고 오른쪽 default 클릭해서 셋팅한다

이제 디컴파일이 되는지 확인하기 위해서 jar 파일을 열고 클래스 파일을 클릭하게 되면

디컴파일된 소스가 화면에 나타나게 된다.

기타 환경설정을 해야되는부분이다. 한글이 깨지는 문제는 Convert Unicode String into ANSI Strings

체크하면 된다.

프로젝트 폴더에 넣었다고해서 디컴파일을 jadclipse 가 다 실행시켜주는 것은 아니다.

몇 개의 원하는 class 파일을 이클립스에서 디컴파일 할려고 할 때 Project build path Libraries

등록 되어있어야 한다. 그림에서 와 같이 Add class folder 클릭하여 원하는 폴더를 체크하면 되는데

없을경우 만들어서 넣고 그 만든폴더에 class 파일이 들어가면되는 것이다

2009/02/19 16:51 2009/02/19 16:51
이 글에는 트랙백을 보낼 수 없습니다
1. 패키지 설치

#sudo apt-get install subversion apache2 libapache2-svn

위의 명령을 이용하여 패키지를 설치한다.


2. subversion 디렉토리 생성 및 권한 설정.

#mkdir /home/svn                                                - 서브버젼에서 사용할 디렉토리
#cd /home/svn                                                    - 이동
#svnadmin create --fs-type fsfs project1                 - 프로젝트 디렉토리 생성  
#chmod -R g+w project1                                       - 그룹쓰기 권한 설정
#chown -R nobody.nogroup proejct1                      - 아파치에서 액세스하기 위한 그룹 설정


3. apache 설정

우분투에서 아파치 설정파일은 /etc/apache2/apache2.conf  이다.
위의 파일에서

LoadModule dav_module              mod_dav.so
LoadModule dav_svn_module        dav_svn.so

<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/project1
</Location>

부분을 추가해 줍니다.


4. 사용자 인증

#htpasswd -c [패스워드파일] [유저아이디]
ex) #htpasswd -c passwd lotus

아파치 설정파일이 있는곳에서 위의 명령어를 하면 패스워를 입력받습니다.
위의 명령어는 새로운 패스워를 만드는 경우고 사용자를 추가할 경우에는

#htpasswd [패스워드파일] [유저아이디]

의 형식으로 추가합니다. 아파치 설정파일에 가서 아까 적어준 부분을 아래와 같이 수정하여줍니다

<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/project1
  AuthType Basic
  AuthName "Subversion Repository project1"
  AuthUserFile /etc/apache2/passwd
  Require valid-user
</Location>

그리고 checkout 모든 사용자들이 할 수 있지만 커밋 등의 쓰기동작은 지정된 사용자만이 할수있게 끔 하려면
<Location /svn/sample>
  DAV svn
  SVNPath /home/svn/project1
  AuthType Basic
  AuthName "Subversion Repository project1"
  AuthUserFile /etc/apache2/passwd
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>
</Location>

이렇게 수정합니다.
설치가 제대로 되었는지 확인하려면

#svn checkout http://(서버 ip or 도메인네임)/svn/project1 project1

을 실행하였을 경우
Checked out revision 0 이 출력 되면 설치가 완료된 것입니다.
2008/10/27 12:06 2008/10/27 12:06
이 글에는 트랙백을 보낼 수 없습니다
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2024/04   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)