Clean Code that Works.

음.. SWT를 이용해 GUI 프로그램을 만드는 중이었는데..

그냥 이클립스의 프로젝트 클린 기능을 실행해 보았더니 갑자기..

Unable to load graphics library [GDI+ is required] 요런 익셉션이 발생했다.

익셉션이 발생한 구간은

GC.setAntialias(SWT.ON);
GC.setInterpolation(SWT.HIGH);

안티얼리어싱, 보간법 설정하는 부분이었다.

구글링을 해본결과...

마소 사이트에 가서 GDIPLUS.dll 파일을 다운로드한 후 windows/system32 폴더에 카피 하라고 하는데..

그 전에는 이런거 없이 잘 실행 됬지만 .. clean 을 실행한후 갑자기 안되었기때문에....

저렇게 해도 역시 안되었다..

oops.

그래서 익셉션이 SWT패키지에서 발생한것임을 생각해서 빌드패스에 SWT 를 추가하니깐 올바르게 실행되었다.

음.. 결론은 약간 삽질 -ㅁ-?

 

처음 예제부터 막혀서 -_-;;

여기저기 찾아 보았다. 루씬 버젼이 올라가면서 책에나온 소스가 deprecate 되어서 동작하지 않았다.

기존 예제를 보면

Document doc = new Document();
doc.add(Field.Text("contents", new FileReader(f)));
doc.add(Field.Keyword("filename", f.getCanonicalPath()));
writer.addDocument(doc);

이렇게 되어있는데 Field 에 Text, Keyword 스태틱 메소드(맞겠지 -ㅁ-?)가 사라져(deprecate) 버렸다.

Document doc = new Document();
doc.add(new Field("contents", new FileReader(f)));
doc.add(new Field("filename", f.getCanonicalPath(), Field.Store.YES, Field.Index.UN_TOKENIZED));
writer.addDocument(doc);

Field의 매개변수 타입에 따라서 속성을 결정 하는 형식으로 바뀌었다.

http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/index.html
루씬 doc 문서를 참조해서 이해 해볼려 했으나.. 이해가 잘 되니 않아 구글링으로 해결했다..OTL

OSGi의 개요.

Java/이론..2007. 7. 24. 10:21
이클립스 RCP 책을 보던 중 이클립스가 OSGi 기반이라는 내용이 나와서 한번 검색해 보았다.

네이버 블로거 휴이님 글 펌


OSGi(Open Service Gateway initiative) Alliance1999년선 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 후 몇 년 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 이 표준 사양의 핵심은 어플리케이션의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.

OSGi 프레임워크는 독립적인 Java/VM 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 어플리케이션 또는 컴포넌트(번들, Bundle)은 재부팅 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled)될 수 있다

OSGi는 Embeddable(어플리케이션 내부로 포함될수 있는) SOA를 구현하고 있다. 이를 통해 어플리케이션 개발에 있어 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)



1. Technology Problem


현재 홈 네트워크를 구성하는데 있어 해결해야 할 많은 난제들이 있으나 기술적으로 가장 우선시 되어야 할 사항은 바로 홈 네트워크를 구성하는 기술의 표준화 이다. 실제 홈 네트워크를 구성하는데 있어 다음과 같은 문제가 있다.

- 서로 다른 적용 분야 (데이터, 엔터테이먼트, 제어 네트워크 등)에
- 서로 다른 통신 방식 (고속, 저속, 유선, 무선, 전력선, CAT5, 2-Wire 등)
- 서로 다른 네트워크 (Ethernet, HomePNA, Bluetooth, HomeRF, IEEE1394, LonWorks 등)과
- 다양한 방법(ADSL, Cable, Phone, PSTN, 위성 등)으로 접속할 수 있어야 하고
- 그럼에도 일관된 홈 네트워크 서비스 (정보검색, 검침, 의료, 보안, 에너지 관리 등) 를 제공할 수 있어야 할 뿐만 아니라.
- 현존하지 않는 새로운 네트워크 기술과 새로운 홈 네트워크 서비스가 등장하더라도 모두 수용할 수 있어야 한다.

이를 가능하게 하는 홈 네트워크 시스템의 핵심은 주거용 게이트웨이(=홈 게이트웨이)이다. 하지만 현재의 주거용 게이트웨이들은 몇 가지의 고정된 기술과 네트워크 기술을 지원하거나 특정 회사의 독점적 기술들을 사용하고 있다. 또한 홈 네트워크 서비스도 고정되어 있거나 자사의 제품에서만 동작한다. 따라서 각기 다른 제조사들의 홈 네트워크 시스템과 제품들은 호환되지 않으며 미래에 등장할 새로운 기술과 서비스를 수용할 방법이 없다.



2. OSGi 설명


OSGi 표준은 번들(Bundle)이라고 불리는 모듈화 된 소프트웨어를 동작하도록 하는 소프트웨어적 프레임워크(Framework)와 번들이 프레임워크와 통신하도록 하는 인터페이스(Interface)를 정의하고 있다. OSGi 프레임워크는 게이트웨이 상의 이기종 기술 또는 타 벤더의 서비스 간에도 통신이 가능하게 하는 표준 기술을 제공한다. 이는 새로운 기술이나 서비스를 제공하는 장치가 추가 되더라도 장치 설비자의 요구 또는 거주자에 의한 간섭 없이도 인터넷을 통해 새로운 소프트웨어 모듈을 손쉽게 설치 및 업그레이드, 교환 시키는 것을 가능하게 한다. 따라서 소비자는 얼마든지 다른 제조사의 이기종 기술을 사용하는 기기를 구입해도 문제 없이 사용할 수 있다. 단지 이것을 가능하게 하기 위해 그 장치에 해당하는 번들을 원격지에서 전송 받기만 하면 되며, 새 장치를 설치하더라도 이전의 이기종 기술을 사용하는 장치들과도 통신 할 수 있다. 이와 같은 특징 때문에 OSGi는 외부망과 내부망, 각 기술과 서비스들간의 “교량”이자 “관문”의 역할을 수행하게 된다.



OSGi를 구성하는 중요 엔터티는 다음과 같다.

 
u       서비스 : 특정 기능을 수행하는 자바 인터페이스와 실제 구현객체
u       번들 : 서비스를 제공하기 위한 기능적 배포 단위
u       프레임워크(번들 컨텍스트) : 번들의 라이프 사이클을 관리하는 번들 실행환경
 
서비스는 미리 정의된 서비스 인터페이스를 통해 접근이 가능한 컴포넌트다. 하나의 애플리케이션은 여러 개의 서비스의 협동작업을 통해 구성되고, 런타임시에 필요한 서비스를 요청할 수도 있다. 프레임워크는 각 서비스와 그 서비스에 해당하는 실제구현에 대한 매핑을 가지고 있고, 간단한 쿼리 메커니즘을 통해 서비스의 실제구현을 찾을 수 있다. 또한 프레임워크는 각 서비스간의 상호 의존관계를 관리한다.
 
번들은 여러 서비스의 구현을 하나의 패키지로 묶은 JAR 파일의 형태로 존재한다. JAR파일에는 하나 이상의 서비스의 구현객체와 리소스 파일 및 매니페스트 파일을 포함하고 있다. 번들 컨텍스트는 프레임워크 내부의 번들의 실행환경이며, 번들의 설치, 실행, 정지 및 삭제 등의 번들의 라이프 사이클을 관리한다.
 
 
 
OSGi 프레임워크는 소용량 메모리 디바이스에서 프로그래밍하는 개발자들이 연속적으로 동작할 수 있는 애플리케이션을 작성할 수 있는 컨텍스트를 제공하는 것이 목적이다. 애플리케이션의 swap-in과 swap-out이 런타임시에 발생하게 되는 이러한 환경에서는 런타임시에 다른 애플리케이션과 구조적이고 의존적인 방식으로 커뮤니케이션을 수행해야 할 필요가 있다. OSGi 프레임워크는 자바 프로그래밍 언어가 가진 코드의 네트웍 이동성을 이용하여 컴포넌트 기반의 개발환경을 제공함으로써, 보다 풍부하고 구조적인 서비스의 개발을 가능하게 한다.
 
OSGi 프레임웍이 제공하고자 하는 환경의 목표는 다음과 같다.
Ø         애플리케이션이 실행 중에도 동적으로 다운로드 및 업그레이드가 가능
Ø         제한된 메모리 디바이스 사용 가능
Ø         효율적이고 통합된 컴포넌트 개발환경 제공
Ø         애플리케이션 간의 의존성에 대한 관리 기능 제공
Ø         확장 가능성(scalable)

RCP 타겟 설정.

Java/이론..2007. 6. 26. 22:24
아. 이것 때문에 또 헤맸다.

이클립스 사이트에 들어가서 RCP 파일을 받아야 되는데 스크롤을 내려보면
RCP runtime Binary 와 RCP SDK 가 있다.
스클롤에 바로 RCP 보인다고 다운 받지 말고 좀더 내려서 밑에 있는 RCP SDK를 받아서
타켓으로 설정하면 사용가능 하다.

이클립스 다운로드 페이지

JSP는 조금 나중에 해야겠다.
ASP와 비슷할 거라고 생각했는데 -_-;; 이클립스 설정하고 이것저것 할려고 하니깐 머리가 너무복잡하다;;
몰라서 못하겠다 -_-; 다른 책으로 한번 보고 다시 봐봐야지(지금 보는책 모델 2로 다시 배우는 JSP)

아무튼. 그래서 RCP를 시작 하는데... swing->SWT->RCP 순으로 책을 보고 있는데 앞에껀 생각이 안난다 --;

책은 이클립스 RCP책을 보고 있는데 5장 실습 시작부터 막혔다 ;;
검색에 검색을 하여 겨우 화면은 띄우는데 성공 --;; 이제 부터 시작이다 후 -ㅁ-

사용자 삽입 이미지

여기 Clear workspace data before launching을 꼭 체크해 줘야한다. 그래야 변경 사항이 적용된다



RCP 책을 보면 plugin.xml에 Extensions탭에서 뷰를 추가하는 형식으로 되어있는데
뷰를 마우스 오른쪽 클릭후 뷰 속성에 대한 상세 입력 방법이 나온다고 되어 있지만 이클립스 3.2.2 버젼에서는 나와 있지가 않다.(내가 못찾을 수도 있다.)
그래서 그냥 템플릿을 통해서 만들어서 띄우는 형식으로 해봤다.
사용자 삽입 이미지

Extension 탭에서 Add버튼을 누른후 ui.views를 선택한후 넥스트

중간에 id나 클래스 명은 자신이 원하는 대로 설정한다. 이렇게 설정하고 나면 아래와 같이 된다.
사용자 삽입 이미지

이렇게 되면 기본적인 뷰가 생성이 된다.


그 다음에는 퍼스펙티브 클래스에 이것을 추가 시켜야 한다.

public class Perspective implements IPerspectiveFactory {
public void createInitialLayout(IPageLayout layout) {
layout.setEditorAreaVisible(false);
layout.addView("org.eclipsercp.hyperbola.views.SampleView", IPageLayout.LEFT, 1.0f, layout.getEditorArea());
}
}




그런 다음에 실행 시켜 보면.
사용자 삽입 이미지

템플릿을 통해 만들었기 때문에 더블클릭이나 다른 이벤트를 기본적으로 지원하는거 같다.



이렇게 하면 일단 가장 처음 단계는 통과.
더 좋은 방법이나 궁금한게 있으시면 댓글 달아 주세요.

1. 생성자는 파라미터가 없어야 한다.

2. 자바 빈즈 컴포넌트의 속성(Property)들은 읽기, 쓰기 중 적어도 하나 이상의 기능을 수행 할 수 있어야 한다.

3. getXXX()는 파라미터를 받지 않은 구조이어야 한다.

4. setXXX()는 반다시 하나의 파라미터를 받는 구조이어야 한다.

JSP 공부중..

  자바에서의 쓰레드는 『프로그램을 실행하는 주체』라고 할 수 있습니다. 그러나 운영체제(OS)의 프로세스(process)도 프로그램을 실행하는 주체라고 말할 수 있습니다. 이번 글에서는 프로세스와 쓰레드의 차이점에 대해서 이야기하겠습니다.

  프로세스와 쓰레드의 관계는 플랫폼의 차이점(OS나 하드웨어의 차이)에 의해서 크게 달라집니다. 플랫폼이 같아도 자바 가상 머신(Java Virtual Machine, JVM)의 구현 방법에 따라 프로세스와 쓰레드의 관계는 달라집니다. 그러나 일반적으로는 하나의 프로세스 안에서 복수의 쓰레드가 구축된다고 해도 맞는 말이 되겠지요.

  쓰레드는 메모리를 공유한다.

  프로세스와 쓰레드의 가장 큰 차이점은 메모리 공유의 유무입니다.

  프로세스는 각각 독립된 메모리 공간을 가지고 있는 것이 보통입니다. 어떤 프로세스가 다른 프로세스의 메모리를 마음대로 읽는다든지 메모리에 쓴다든지 하는 것은 아닙니다. 프로세스의 메모리 공간은 각각 독립되어있기 때문에 어던 프로세스가 다른 프로세스 때문에 망가질 위험이 없는 겂입니다.

  쓰레드는 메모리를 공유합니다.[주] 하나의 쓰레드가 메모리 상에 정보를 쓰고 그것을 다른 쓰레드가 읽는 것은 자주 일어나는 일입니다. 『메모리를 공유하고 있다』라는 것은 자바에서 말하면 『인스턴스를 공유하고 있다』라는 의미입니다. 자바의 인스턴스는 메모리 상에 있고 복수의 쓰레드가 그 인스턴스를 읽고 쓸 수 있도록 되어 있습니다.

[주] 자바의 메모리 모델에서는 메인 메모리와 워킹 메모리라는 두 종류의 메모리가 등장합니다. 이 때에 쓰레드가 공유하는 것은 메인 메모리 쪽입니다.

  쓰레드가 메모리를 공유하고 있기 때문에 쓰레드 간의 통신은 매우 자연스럽고 간단히 실현될 수 있습니다. 어떤 쓰레드가 인스턴스에 정보를 써서 다른 쓰레드가 그 인스턴스에서 정보를 읽으면 되는 것입니다. 한편 같은 인스턴스에 복수의 쓰레드에서 접근하기 때문에 배타 제어를 바르게 해야 합니다.

  쓰레드는 콘텍스트스위치(context-swith)가 가볍다.

  프로세스와 쓰레드의 또 하나의 차이점은 콘텍스트 스위치의 무게입니다.

  동작중인 프로세스가 바뀔 대 프로세스는 현재 자기의 상태(콘텍스트 정보)를 일단 보존합니다. 그리고 새롭게 동작 개시하는 프로세스는 이전에 보전해 두었던 자신의 콘텍스트 정보를 다시 복구합니다. 이와 같은 정보의 바꿈(context-switch)에는 시간이 걸립니다.
 
  동작중인 쓰레드가 바뀔 때 쓰레드는 프로세스와 같이 콘텍스트 스위치를 행합니다. 그러나 쓰레드가 관리하고 있는 콘텍스트 정보는 프로세스보다도 적기 때문에[주] 쓰레드의 콘텍스트 스위치는 프로그램의 콘텍스트 스위치보다도 가볍게 행해지는 것이 보통입니다.

[주] 이것은 어디까지나 일반적인 이야기 입니다. 쓰레드와 프로세스의 실제의 관계는 자바 실행 처리계의 구현에 크게 의존합니다.

  그러므로 빽빽히 연달아 쉬고 있는 복수의 작업을 행하는 경우에는 프로세스보다도 쓰레드쪽이 좋은 경우가 많이 있겠지요.
- Java언어로 배우는 디자인 패턴 입문 -







import java.util.Scanner;

public class CheckPrimeNumber {
 private int input;
 private Scanner scan = new Scanner(System.in);
 private boolean prime;
 
 public CheckPrimeNumber() {
  putInfo();
 }
 
 public void setInputNumber(int input) {
  this.input = input;
 }
 
 public void putInfo() {
  System.out.println("소수 계산 프로그램 입니다.");
 
  System.out.print("계산 하고자 하는 수를 입력 하세요 : ");
  setInputNumber(scan.nextInt());
 
  System.out.println("계산중...");
 
  putNumber(input);
 }
 
 public boolean calculation(int num) {
  prime = true;
     int limit = (int) Math.sqrt ( num ); 

     for ( int i = 2; i <= limit; i++ )
     {
      if ( num % i == 0 )
      {
       prime = false;
       break;
      }
     }
     return prime;
 }
 
 public void putNumber(int num) {
  int j = 0;
  for (int i = 2; i <= num; i++){
   if (calculation(i)) {
    System.out.println(i);
    j++;
   }
  }
  System.out.println("입력한 숫자 "+input+"의 소수의 갯수는 "+j+"개입니다.");
 }
 
 public static void main(String[] args) {
  new CheckPrimeNumber();
 }
}

http://www.ibm.com/developerworks/kr/library/j-ap01117/index.html?ca=dnn-krt-20070503

이클립스 플러그인 설정.

GUI 프로그래밍을 할때는 각 컴포지트의 구성도 중요하지만 이벤트의 처리도 중요한것 같다.

SWT/JFace in action 책을 보면.

복잡한 사용자 인터페이스는 이 두가지 이벤트 처리 수단을 모두 사용해야 한다.

JFace가 메뉴, 툴바, 버튼에 대한 빠른 인코딩이 가능한 한편, SWT는 키보드 작동 및 Shell과 테이블 같은 위젝과 관련한 이벤트에 필요하다.또한 JFace 클래스는 오른쪽 클릭과 왼쪽 클릭을 구분해야 할 때는 별 쓸모가 없다.
그러므로 GUI 개발자가 최소의 코드량으로 최대의 성능을 내고자 한다면 양쪽 툴셋에 모두 익숙해 져야한다.

위의 내용을 항상 명시하며 가볍고 깔끔한 코드를 가지는 프로그래밍을 하도록 하자.