이 블로그 검색

2012년 7월 25일 수요일

Spring Remote (RMI) 예제


오늘 살펴볼 스프링 Remote 중에서 RMI 지원은 단순한 POJO 작성만으로도 RMI 서비스를 간편하게 발행할 수 있게 해준다. 간단한 예제를 작성해보자. 일단 프로그램은 java application 으로 하였다. RMI를 통한 통신이므로 서버 및 클라이언트 2개 프로젝트를 만들어야 한다. 먼저 서버를 만든다.

* 서버 작성 *

소스코드는 다음을 참조한다. https://github.com/jeremyko/MySpringRMI

1. Eclipse 에서 신규 프로젝트를 생성한다.

File -> New -> java project -> "MySpringRMI" 프로젝트 생성. 그리고 스프링 관련된 라이브러리들을 프로젝트 속성 -> Java Build Path -> Libraries 에 모두 추가한다.

2. 스프링 설정파일을 다음과 같이 설정한다.

// spring_conf.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:p="http://www.springframework.org/schema/p"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

  <bean class="org.springframework.remoting.rmi.RmiServiceExporter"
    p:service-ref="helloService"
    p:serviceName="HelloService"
    p:serviceInterface="kojh.spring.rmi.HelloService" />

  <bean id="helloService" class="kojh.spring.rmi.HelloServiceImpl"/>
</beans>

<!-- p:registryPort="1107" -->

service-ref 에는 서비스를 담당할 bean 즉, helloService로 설정한다. serviceName 속성을 통해서 RMI 서비스명을 HelloService 로 설정한다, 나중에 보게 되겠지만 이것을 참조해서 client가 이 서비스를 호출하게 된다. serviceInterface 는 해당 서비스가 구현하고 있는 인터페이스를 설정한다. 참고로, 기본적으로 RMI가 사용하는 포트는 1099 이다. 이값을 변경하기 위한 속성은 registryPort 이다.

3. 서비스 인터페이스를 정의한다.

// HelloService.java
package kojh.spring.rmi;

public interface HelloService
{
    String sayHello(String name);
}

2012년 7월 24일 화요일

MyBatis-Spring : mapper interface 와 annotation을 활용한 게시판 예제


MyBatis-Spring : mapper interface 와 annotation을 활용한 게시판 예제

지난번 MyBatis-Spring 에 대한 소개 에 이어서, 이를 활용한 간단한 게시판 작성 예제를 작성해본다. XML파일에 맵핑을 정의하지 않고, mapper interface 와 annotation을 이용해서 처리하는것으로 해봤다. 게시판은 전체 목록 출력, 검색기능, 내용보기 및 수정, 삭제등의 아주 기본적인 기능만을 다루고 있다. 이 프로젝트의 소스는 다음 위치에 있으니 참조하시길 바란다.
https://github.com/jeremyko/SpringMvcBoardMyBatis

1. 우선 기본적인 스프링 MVC 프로젝트를 생성한다. 
간단하게 설명하기 위해서 스프링 환경 설정 부분은 생략했다. 일단 사용된 툴만 적어 보면 다음과 같다 (환경들은 알아서들 잘 맞추시길..자바는 환경 설정이 제일 어려운것 같다.^^).

- Eclipse Indigo(3.7)
- apache-tomcat-7.0.27
- Maven Integration for Eclipse
- SpringSource Tool Suite (STS) for Eclipse Indigo(3.7) 

- 데이터베이스: oracle 11g XE
사용된 이클립스 플러그인은 help -> Eclipse Marketplace 에서 검색.

이클립스 file -> new -> others -> SpringSource Tool Suite -> Spring Template Project -> Spring MVC Project 로 프로젝트를 생성.
그다음 pom.xml 파일을 열어서 dependency에 mybatis-spring 을 추가한다
    <!-- MyBatis -->
    <dependency>
      <groupId>org.mybatis</groupId>
      <artifactId>mybatis-spring</artifactId>
      <version>1.1.1</version>
    </dependency>


추가된 dependency를 반영하기 위해서 Run As -> Maven install을 수행한다.

Run As -> Run on Server로 생성된 프로젝트가 정상 작동 하는지 확인하기 바란다.
Hello World 라고 큼지막하게 웹 페이지가 뜨면 성공이다.

2. 게시판 테이블 및 seq 생성
이 예제에서는 오라클을 이용하고 있다. XE버전은 무료라서 개인이 사용하기에 좋은것 같다. 단지 단점이라면 리소스를 많이 잡아먹는다 (500 MB 메모리 사용). 이클립스가 사용하는 리소스도 상당한데, Oracle까지 돌리면 기본 1GB 정도는 그냥 두놈이 차지하게 된다. 컴에 램이 4GB 는 되어야 좀 돌릴만하다. 만약 다른 DB를 사용한다면, 아래의 내용을 참조로 수정이 필요할 수도 있겠다.

    CREATE SEQUENCE   "SEQ_ID"  MINVALUE 1 MAXVALUE 99999999999
    INCREMENT BY 1 START WITH 1 ;

    CREATE TABLE  "SPRING_BOARD"
    (
       "ID" NUMBER(10,0) NOT NULL,
       "SUBJECT" VARCHAR2(50),
       "NAME" VARCHAR2(50),
       "CREATED_DATE" DATE,
       "MAIL" VARCHAR2(50),
       "MEMO" VARCHAR2(200),
       "HITS" NUMBER(10,0),
        PRIMARY KEY ("ID") ENABLE
    ) ;


2012년 7월 20일 금요일

RIP, Jon Lord

                                                     Jon passes from Darkness to Light.
Jon Lord 9 June 1941 – 16 July 2012.





2012년 7월 18일 수요일

Git 활용 (기본적인 사용법)

http://gitimmersion.com/
 

http://try.github.com/levels/1/challenges/1



* 설정 

git config --global user.name "Your Name"
git config --global user.email "aaa@bbb.com"

라인 ending 설정 (윈도우경우)

    git config --global core.autocrlf true 

    git config --global core.safecrlf true

인코딩 설정:  윈도우 환경일 경우.

    git config --global i18n.commitEncoding cp949 

    git config --global i18n.logOutputEncoding cp949 

    물론 인코딩이 utf8 이라면 

    git config --global i18n.commitEncoding utf8 

    git config --global i18n.logOutputEncoding utf8


SSH-Key 생성

    ssh-keygen -t rsa

* 추적하지 않을 파일 설정하기

    .gitighore 파일을 생성, 패턴을 기술.

    echo "*.security" > .gitingnore
   
* 현 설정 확인

    git config --list


* Repository 생성

    git init

* 상태 확인  

    git status
   
* 변경사항을 staging 하기

    git add test.c
    git add .
   
    staged 상태 : Git가 변화를 인지한 상태, git add 를 수행하면 됨.
    아직 commit을 안한 상태이기때문에 변경사항이 영구적으로 저장된 상태가 아님을 나타냄.
   
* 커밋

    git commit -m "Changes for a and b"
    혹은 vi등 편집기를 통해 메시지 편집 시에는 그냥 git commit

    주의) 파일 수정후 add, 다시 파일 수정후, commit 을 하면,
    2번째 수정 사항은 staging안된 상태이다.
    커밋을 해도 2번째 수정 사항은 저장안됨.
    이때는 2번째 수정 사항에 대한 add 도 수행하고 그것에 대한 commit도 다시 수행 해야함.

     간혹 빈 commit 을 만들어서 push 해야 하는 경우가 (github pages 에 실패한 deploy를 다시 수행하는 경우 등등) 있는데, 다음처럼 수행하고 git push 한다.

     git commit --allow-empty -m "empty commit"  
   
* 이력보기

    git log git log --pretty=oneline --max-count=2
    git log --pretty=oneline --since='5 minutes ago'
    git log --pretty=oneline --until='5 minutes ago'
    git log --pretty=oneline --author=<your name>
    git log --pretty=oneline --all
    git log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
    git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

    아직 커밋 안된 상태 에서 변경 사항 알아내기
     
        git diff HEAD 파일명       
        HEAD란 최종 커밋을 의미.

    2개 커밋 간 변경된 파일 목록 조회     
   
        git diff --name-only <commit hash1> <commit hash2>

    각 commit 별 변경된 파일 목록 조회

        git log --name-status


* 이전 버전 가져오기

    git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
   
    * cdb6848 2012-07-18 | 3 commit (HEAD, v1, origin/master, master) [kojunghyen]
    * b5cda22 2012-07-18 | 1st [kojunghyen]
    * 2314983 2012-07-18 | 2 commit [kojunghyen]
    * ece0e9f 2012-07-18 | first commit [kojunghyen]
   
    git checkout <hash>
   
    ex: git checkout 23149839d82ce5f104aa6fba72b201566da44ec6
   
    다시 master branch의 최신 버전으로 돌아오려면,
   
    git checkout master
   
    'master’ is the name of the default branch.
    By checking out a branch by name, you go to the lastest version of that branch.
   
   
* 태그 붙이기

    현재 버전을 v1이라고 하기로 하자.
        git tag v1
   
    바로 이전 버전을 가져오는 방법
        git checkout v1~1 => v1^
       
        ^ notation to indicate “the parent of v1”   
    이 이전 버전을 v1-beta라고 태그를 붙이자.
        git tag v1-beta
   
       
* 태그 조회
   
    git tag

* 태그 삭제 (로컬)  
   git tag -d <tag명>
* 태그 삭제 (원격)  
   git push --delete origin <tag명>
* 태그 삭제 (tag 명이 브랜치명과 같은 경우)
   -> 명시적으로 tag임을 지정해서 삭제해야 함   
   git push origin :refs/tags/<tag명> 


* stage->un-staged 상태로 변경하기

    git reset HEAD myfile


* 수정한 내용을 무시하고 처음 상태(최근 커밋된 버전으로)로 되돌리기

    git checkout -- myfile


* 커밋된 변경 되돌리기

    git revert HEAD
   
    This technique will work with any commit (although you may have to resolve conflicts).
    It is safe to use even on branches that are publicly shared on remote repositories.


* AMENDING COMMITS (커밋 수정하기, 혹은 기존 커밋에 추가하기)

    git commit --amend 

    add, commit된 상태에서 수정이 발생하였고 이전 커밋에 포함하고 싶은 경우(2개의 커밋생성없이).

* 여러개의 COMMIT들을 하나의 C OMMIT으로 합치기
    다음처럼 커밋 히스토리가 존재할때
    git log --oneline
    -->
    commit4
    commit3
    commit2
    first commit
    3,4 커밋을 합치고 싶은 경우,

    git rebase -i HEAD~2
    pick .......
    pick .......
    이것을 다음 처럼 변경  (출력 순서 주의 : 제일 위가 제일 오래된 커밋 이다, git log 와 반대)
 
    pick     ...
    squash ...
       
* MOVING FILES

    git mv hello.rb lib

    혹은 add 후 제거,

    git add lib/hello.rb

    git rm hello.rb
   
   
* branch 만들기
   
    git checkout -b 브랜치명

    => 이후 브랜치내에서 작업을 수행하고 commit한다.

    브랜치를 선택할 경우는

    git branch -a

    => 브랜치들을 리스트업, 이후 선택할 브랜치를 checkout 하면 됨

    git checkout master

    git checkout greet

   
* branch 제거
   
    git branch -d 브랜치명
   

* Merging

    git checkout greet

    git merge master

    => master변경분을 greet에 merge시킨다.


    예: clean_up branch를 만들고 작업후 master branch로 돌아와서 merge수행시
    git merge clean_up
   
   
* branch 변경 비교하기

    git diff --color branch1..branch2


* branch내에서 commit간 변경 비교하기

    git diff --color commit_hash1 commit_hash2

    => hash 시작 문자 일부만으로도 가능.


* 충돌 해소

    여러개의 BRANCH간 CHECKOUT시 불일치 발생 경우면 수동으로 해당 파일 수정후 ADD, COMMIT.


* branch push/pull 하기

    자신이 생성한 branch 를 원격저장소에 push

    git push origin my-branch


    원격 브랜치 가져오기: 먼저 원격 브랜치 확인

    git branch -r

    git checkout -b 생성할브랜치이름 원격브랜치이름

    동일한 이름을 사용한다면 -t 옵션 사용

    git checkout --track 원격브랜치이름


* REBASING VS MERGING

    rebase는 말 그대로 베이스를 다시 잡는 작업이다.
    변경사항을 적용할 기준(베이스) 브랜치를 지정하고 현재 브랜치의 변경사항을
    그 기준되는 브랜치에 적용을 하여 선형적인 커밋 히스토리를 만들어주므로
    지저분하지 않게 된다.

    다음설명이 가장 잘 이해됨.
    Choose to merge when you have a feature on a separate branch and want to bring that
    code into master or another branch.(feature branch 만들어서 다른branch 와 합칠거면
    merge 를 사용해라. 즉 일반적인 용도에 사용)

    Choose to rebase when you want to stay in sync with the main branch
    when you’re working on a long-lived side branch.(없어지지않고 계속 사용될 branch 와
    main branch 가 일치된 내용으로 가고싶을경우 rebase를 사용해라)

    다음 링크에서도 rebase 에 대해서 그림으로 잘 설명됨.
    rebase를 사용하지 말자는 내용임. feature branch에서 에러가 발생되면 rebase 시 
    모든 commit 에 에러가 포함되는 문제를 지적하고 있음. 
    그냥 간단하게 merge 를 사용하는게 좋다.
    https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

    When to Rebase, When to Merge?
        Don’t use rebase … 커밋 히스토리를 변경시키기 때문이다.
        http://stackoverflow.com/questions/3357122/git-pull-vs-git-fetch-git-rebase
      
        정확한 커밋 히스토리가 중요한 경우에는 리베이스 사용을 자제.
   
    하지만 동일한 branch인 경우에는 선택의 여지가 있음 (아래 git pull 참고)


* add a remote repository

    git remote add origin git@github.com:jeremyko/try_git.git


* git fetch

    원격저장소의 변경사항 가져와서 원격브랜치를 갱신.


* Pushing Remotely

    로컬 변경을 origin repo (on GitHub)에 반영한다.
    -u 옵션은 입력인자들을 기억하는 옵션이다.
    이 경우 다음부터는 git push 만 입력하면 된다.
   
    git push -u origin master
   

* Pulling Remotely

    git pull
   
    remote repository의 변경사항을 가져온다. 그런데 pull명령은 다음과 동일하다.
   
    git fetch 
    git merge origin/master

    즉 변경 내용을 가져온후, 로컬의 변경사항과 머지하는작업이 동시에 일어난다.

    git pull --rebase
   
    pull 사용 시 매번 merge commit 이 생기는게 필요없는 경우
    (즉, 동일한 master branch만 pull로 가져오는 경우, master 브랜치끼리 merge commit 은
     불필요 할수 있으므로)
    --rebase 옵션을 주면 merge commit log 가 발생 하지 않게되어,
    좀 더 직관적인 이력관리가능.
   
* log 

    commit history 로그 보기.
    특정 사용자의 commit history 만 보고 싶다면, git log --author=userid

    특정 파일에 대한 log를 보고 싶으면, git log /xxx/yyy/source.hpp   

* stash

    만약 local의 변경 사항을 임시로 저장했다가 나중에 다시 적용하고 싶다면 'git stash' 로
    변경사항을 stash 한 다음, git stash list 로 목록을 확인할수 있다.
    예를 들면, feature branch에서 이슈에 대한 수정을 진행 중인데, master branch로 패치된
    내용을 반영하고 작업을 해야 하는 경우, commit 후에 master branch와 merge 할 필요없이
    stash로 수정사항을 보관 후, master 와 merge 후 다시, 작업 중이던 수정 사항을 반영 하면
    다시 이전과 같은 개발 중 상태가 된다.
   
    'git stash apply' 명령을 pull 작업 이후에 실행해서 재 적용 시킨다.
    git stash drop 을 수행해야 list 에서 삭제된다.
    (git statsh apply 대신 git stash pop 을 수행하면 자동으로 list 에서 삭제된다)
   
   
* cloning

    원격 저장소에 있는것을 복제하기 위해서는 git clone을 사용한다.
   
    git clone https://github.com/jeremyko/kothreadpool.git 

    git clone user@61.40.220.178:/path/rep_name.git my_repo_name

* Mac 사용시, .DS_Store 파일이 커밋되는것을 막으려면

    http://hints.binaryage.com/how-to-remove-ds-store-files-from-a-git-repo/


* local GIT Server 설정

    동일한 서버에서 여러 개발자가 개발하는 경우 간단하게 설정 가능.
    서버 위치는 /USER/kojh/serverRepository.git 디렉토리라고 가정.
    소스 존재 위치는 /USER/kojh/MySrc 라고 가정(이미 git init된 상태).

    1. remote 서버 역활 구성
   
        cd /USER/kojh/serverRepository.git
   
        git init --bare
   
   
    2. 소스를 서버에 push
   
        cd /USER/kojh/MySrc
   
        git remote add origin /USER/kojh/serverRepository.git
   
        git push -u origin master
   
   
    2. 개발자 1 의 작업
   
        git clone /USER/kojh/serverRepository.git dev1WorkSpace
   
        git remote add origin /USER/kojh/serverRepository.git
   
   
    3. 개발자 2 의 작업
   
        git clone /USER/kojh/serverRepository.git dev2WorkSpace
   
        git remote add origin /USER/kojh/serverRepository.git
   
   
    4. 이제 개발자1,2 가 일반적인 commit, push, pull 을 수행.


2012년 7월 17일 화요일

MyBatis-Spring




********************************************************************************
Getting Started
********************************************************************************


- 설치

MyBatis-Spring 을 이용하기 위해서는 mybatis-spring-x.x.x.jar 과 그 dependency들을 클래스 패스에 추가해야 한다. Maven을 사용중이라면 pom.xml 에 다음 dependency 를 추가한다.

<dependency>
  <groupId>org.mybatis</groupId>
  <artifactId>mybatis-spring</artifactId>
  <version>x.x.x</version>
</dependency>

- Quick Setup

스프링 어플리케에션 컨텍스트에는 기본적으로 다음 2가지가 필요하다.

1. SqlSessionFactory
2. 최소 하나이상의 mapper interface

SqlSessionFactory를 생성하기 위해 SqlSessionFactoryBean 이 사용된다. 즉 다음처럼 스프링 설정파일에 선언해야 한다.

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource" />
</bean>

데이터 소스가 필요한것을 잊지 말것. 그 다음 Mapper Interface 가 필요하다.

public interface UserMapper {
  // mapper XML 파일 대신 annotation 사용가능!
  @Select("SELECT * FROM users WHERE id = #{userId}")
  User getUser(@Param("userId") String userId);
}

2012년 7월 13일 금요일

베란다 화단 덮개 및 평상 만들기

이사올때부터 아..베란다에 공사좀 해야겠다라고 생각했었는데, 
이후 몇년동안 말만 하다가 드디어 지난 2012.6.2 부터 공사를 시작했다. 
일단 필요한 목재 견적을 내서 주문을 했는데 지금 보니 목재비가 만만치 않게 들었다. 
작업하다가 아이폰으로 간간히 찍은 사진들이다.









tomcat maven plugin : 이클립스-maven 플러그인을 이용해서 생성된 웹프로젝트를 Tomcat7.x 에 자동 deploy후 실행시키기


간만에 자바 공부 좀 하려니 역시.. 아주 오래전 느꼈던 감정을 다시 느끼게 된다.
자바 == 짜증나게 많은 라이브러리, 툴, 트릭 및 팁의 연속... - - ;;

이클립스-maven 플러그인을 이용해서 생성된 웹프로젝트를
Tomcat7.x 서버에서 실행해보기 위해서는 , 직접 사용자가 톰캣 서버의 manager로 들어가서
war파일을 deploy하는 방법도 있지만, 번거롭다.
이클립스 상에서, 간단하게 마우스 조작만으로 톰캣서버에 자동으로 deploy 시킬수 있게 해주는  
것이 tomcat maven plugin 이다.

1. 리소스 다운로드


   - 이클립스-maven 플러그인 다운로드: help -> eclipse Marketplaces -> "Maven Integration for Eclipse"
   
   - 톰캣 WAS 설치  
2. 이클립스에서 톰캣서버로 직접 deploy하기 위한, 권한이 필요하므로, 톰캣서버 사용자를 등록한다
   (이미 기존 사용자가 존재하면 불필요)

    <tomcat-users>
      <role rolename="manager-script"/>
  <role rolename="manager-gui"/>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <user username="admin" password="1111" roles="admin,manager,manager-gui,manager-script"/>
</tomcat-users>
2. 이클립스-maven 플러그인을 사용해서 Maven 프로젝트 생성.
   
    New -> Maven Project

3. 해당 maven 프로젝트, pom.xml 파일에 tomcat maven plugin 을 정의한다.

  <build>  
  ....  
    <plugins>
     <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>tomcat-maven-plugin</artifactId>
     <version>1.1</version>
     <configuration>
     <charset>UTF-8</charset>
     <mode>war</mode>
     <url>http://localhost:8080/manager/text</url>
     <path>/spring-security-test</path>
     <username>admin</username>
     <password>1111</password>
     </configuration>
     </plugin>
    </plugins>
    </build>    
4. 프로젝트 Run설정에 Goal 에 tomcat:redeploy 를 설정한다.

5, 실행:  

   - 톰캣서버는 이미 기동된 상태여야 한다.

   - 톰캣서버에 deploy시킨다: 프로젝트 -> 오른쪽 버튼 -> Run As -> Maven Build    

   - 그다음, 웹 브라우져를 열어서
     http://localhost:8080/spring-security-test/ 입력.

2012년 7월 5일 목요일

spring3 + Hibernate4 예제

******************************************************************
hibernate4 예제
******************************************************************



최근의 자바 개발 환경에 약간이라도 익숙해져 볼 맘으로 작성해 보았다. 그런데 보다시피 이 간단한 예제(테이블에 insert) 하나를 수행하기 위해서도 설정할것, 알아야 할것이 많다. 10년전쯤 자바 개발 하다가 이런 설정과 환경에 질려버렸던것 같은데 지금도 별로 좋아진것 없는것 같다.  수많은 설정...설정.... 



간단한 고객 데이터를 테이블에 저장하기 위한 예제를 작성해본다.사용된 개발환경은 다음과 같다
- hibernate-release-4.1.3.Final
- 데이터베이스: oracle 11g XE