Mobile Convergence

위키북스의 OSGi & Spring DM을 읽으면서 Spring DM쪽의 내용을 요약해 본다 

▶ 동영상 자료

  - IBM DeveloperWorks : 안영회/이일민 개념 및 개발하기 (맨 하단의 Next 클릭해서 봄)

▶ 간단 요약 (Ch. 11)

  - 서비스 레지스트리를 사용하는 OSGi의 서비스 룩업 메커니즘을 스프링에서 제공하는 의존성 주입 형태로 사용할 수 있게 해준다. (그림 참조)

  - SpringDM은 OSGi상에서 Extender 개념을 이용하여 POJO(Plain Old Java Object) 형태의 일반 스프링 빈을 OSGi번들로 동적으로 바꾸는 작업을 지원한다 (Extender : 동적으로 설치되는 번들/서비스의 설치/삭제 시 이벤트를 받아서 특정 동작을 수행함)

    + SpringDM OSGi Extender : META-INF/spring/*.xml 파일을 읽어서 스피링 빈으로 초기화 한다

    + SpringDM Web Extender : war 확장자 배포하거나 WEB-INF 폴더를 가지고 있으면 웹컨테이너에 등록시킴 

  - POJO A가 BundleActivator -> BundleContext로 Service Registry에 Service A등록이 되고 ServiceTracker -> BundleActivator를 통해 Service A를 찾아 POJO B가 사용한다 (참조)

  - OSGi 번들은 BundleActivator, ServiceTracker Interface에 의존하나 SpringDM은 spring.xml 과 POJO 만을 필요로 한다 

    + POJO기반으로 번들을 만들어 테스트가 용이하다

    + 번들, 라이프사이클, 버젼닝, 동적 추가/수정/삭제 등의 기능을 엔터프라이즈급 애플리케이션을 개발할 때 사용할 수 있게 됨

  - SpringDM 개발 = Eclipse STS(Spring Tool Suite) + Maven Plugin(v 3.0.4) 설치

  - Eclipse에 Target Platform을 설정한다 (T.P = 번들을 개발하고 실행하는 환경을 의미함. 사용자 Target Platform 만들기 참조)

  - OSGi로 관련 Bundle을 별도의 Plug-In Project로 만들다 보면 Working set으로 묶어서 관리하고 싶어진다. 이를 위한 설정은    WhiteShip 브로깅을 참조한다

  - SpringDM은 Spring Application Context : Bundle = 1:1 관계이다 

1. Plug-in Project를 생성한다 (이클립스 플러그인 프로젝트는 기본적으로 이클립스 Equinox OSGi를 이용한다)

Node.js로 개발한 간단한 애플리케이션을 CloudFoundry로 배포해 보자. 현재 클파(CloudFoundry)는 무료이지만 조만간 유료로 가지 않을까 생각된다. 특징을 보자 

▶ 클파 설치하기

  - 우선  http://www.cloudfoundry.com/  으로 가서 Sign Up 한다 (신청한 메일계정으로 비밀번호가 온다)

  - http://www.rubyinstaller.org/ 사이트로 가서 ruby를 설치한다. (설치시 path 설정여부에 check를 한다. ruby의 gem을 사용하기 위함으로 node.js의 npm와 같은 package 설치 관리자로 보면 된다)

  - d:>gem install vmc  (클파 관리 유틸 vmc를 설치 한다. 한참을 설치하니 그냥 기다리자)

  - vmc의 target을 클파로 지정을 한다 (api.cloudfoundry.com) 그런후 신청한 계정으로 로그인을 한다

  - 하단에 첨부된 파일 적절한 위치에 푼다음 해당 디렉토리로 이동한다

  - 클파에 애플리케이션을 Push 한다 (vmc push <URL해드> 예) vmc push nulpulum 으로 하면 웹 호출 주소가 http://nulpulum.cloudfoundry.com 이 된다. 자세한 사항은 vmc help 로 살펴보자. 최초에는 사용하려는 service에 대하여 물어본다 이때 mongoDB 1개만을 만든다.)

  - 배포된 애플리케이션의 정보를 보자

  - 브라우저에서 호출하여 보자 

  - 간단하게 자신의 애플리케이션을 배포하여 바로 확인해 볼 수가 있다. 등록가능한 애플리케이션에 대해 보려면 vmc services 명령으로 확인해 보면 된다. 

* 첨부파일 : Node.js + Express + MongoDB를 사용한 간단한 CRUD 애플리케이션 

cloudFoundry mongodb.zip

<참조>

  - Open Source Cloud PaaS

  - Spring쪽에서 만든거라 Spring Framework을 지원하고, Node.js등 최신 기술을 지원한다 

  - 클파 이해하기

  - 클파 VMC 사용

예전 프로젝트할 때 WAS를 재기동하지 않고 애플리케이션과 SQL을 관리툴을 통하여 reloading 하는 프레임워크를 만든적이 있다. 또는 솔루션에서 액션을 수행하는 어뎁터 Java 코드를 관리툴을 통하여 입력하면 WAS의 재기동없이 신규 및 업데이트가 가능하게 한적이 있다. 그때 마다 사용했던 것이 ClassLoader 이다. 

좀 더 발전적이게 Plugin처럼 만들고 싶다는 생각을 했지만 게으름으로 미루다 OSGi에 관심을 갖게 되었다. 솔루션을 만들때 통신, 데이터 관리, 어드민 관리, 서비스등을 별도의 버전으로 관리하고 싶었다. OSGi 이면서 J2EE와 같은 Enterprise급 또는 솔루션 개발을 진행할 수 없을까 고민하던 중 찾은 Eclipse Virgo!  

  - 이일민씨의 기고글 : Virg 들어가기

  - Ted Won씨의 블로그 : Virgo 이해

  - 공식 Virgo Wiki

딱 내가 찾던 미들웨어 기능을 고스란히 가지고 있는 Eclipse Virgo를 사용해 보자 

Virgo는 두가지 종류의 버전을 제공한다 

  - Virgo Kernel : Runtime Platform for OSGi based java applications

  - Virgo Web Server : Virgo Kernel + Tomcat Server, OSGi based Web Application 배포 가능 

  1) 다운로드 :  http://www.eclipse.org/virgo/download/ (현재 v3.5.0)

  2) Virgo Server for Apache Tomcat 으로 시작해 보자

  3) bin/startup.bat 를 수행하면 OSGi bundle를 로딩하고 tomcat이 시작된다

  4) 웹 admin console을 들어가 보자 (http://localhost:8080,  id: admin pwd: springsource)

  5) 상단의 메뉴를 클릭하면 반영된 bundle내용 및 기타 상태정보와 deploy등을 수행할 수 있다

  6) Virgo에서 제공하는 모니터링 툴을 실행해 보자 (<Virgo_Home>/bin/jconsole.bat 실행)

  7) jconsole 로그인 (admin / springsource)

  8) JVM에 대한 기본적인 모니터링 항목(memory, thread info, loaded classes, tomcat JMX info) 등을 다양하게 모니터링 할 수 있다 

[Overview] 탭에서 Memory, CPU, Thread수, 로딩된 Class수 등을 볼 수 있다. 

[Threads] 탭에서 각 스레드의 정보를 볼 수 있다. 하단 왼쪽의 스레드를 클릭하면 하단 오른쪽에 정보가 나온다. 

[MBeans]탭에서 Tomcat의 JMX 뿐만 아니라 Virgo 관련 JMX 정보도 볼 수 있다 

  9) Virgo가 사용하는 기본 Library Path(repository/ext)와 유저 Library Path (repository/usr). 기본 OSGi Bundling만 인식한다 

  10) Log는 configuration/serviceability.xml 안에 설정을 하면 serviceability 디렉토리에 로그가 쌓인다 (logback 사용)

  11) OSGi telnet console을 사용하고 싶다면 configuration/osgi.console.properties 중 telnet.enabled=true 로 수정 그리고 Virgo를 재기동한다

  12) OSGi CLI 기반 연결 기본 port 는 2401 변경하고 싶다면 위의 properties파일에서 포트 번호를 변경하고 접속한다

  13) osgi> lb 명령을 수행하면 현재 번들의 상태를 알 수 있다

  14) 번들을 보면 OSGi Kernel, Apache Felix, Apache MINA등이 Active이고 Spring, SLF4J 등이 Resolved 상태이다

OSGi Layer에서 최상위에 있는 서비스 Layer는 번들이 서로 동적으로 협동하여 작업할 수 있도록 하는 방법을 제공한다. OSGi의 서비스는 SOA 처럼 구동된다 

  - Repository에 서비스를 Publish 한다

  - 클라이언트는 서비스를 Find 한다

  - 서비스가 찾아지면 클라이언트는 Repository와 Bind 된다

  - clazz : 해당 서비스 객체의 패키지명 + 인터페이스명, <Interface>.class.getName()  으로 얻어온다 

  - Service : 인터페이스 구현체, new 로 생성한다 

  - properties : 서비스 속성, SERVICE_VENDOR (같은 인터페이스 상속시 구분 명칭), SERVICE_RANKING (서비스 호출 우선순위)

  - BundleContext.getServiceReference(<interface>.class.getName())으로 호출하여 ServiceReference 객체를 얻는다

  - 다음 BundleContext.getService() 인자값으로 얻어도 ServiceReference 객체를 넘기면 실제 서비스 객체를 얻을 수 있다.

* BundleContext API 참조 : http://kickjava.com/src/org/osgi/framework/BundleContext.java.htm

* 참조 샘플 : http://xguru.net/446

Bundle은 BundleContext에 의한 생명주기 관리가 이루어진다. 기본적으로 BundleContext 객체는 Bundle이 생성될 때 인자로 전달이 된다. 또한 OSGi 프레임워크와의 연결 통로이다. BundleContext는 OSGi Layer에서 LifeCycle Layer를 담당한다.

▶ BundleContext의 하는 일

  - OSGi에 새로운 번들 설치

  - OSGi에 설치된 다른 번들 리스트 및 정보 읽어오기

  - OSGi에 등록된 서비스 리스트 및 서비스 객체 가져오기

  - 서비스나 번들의 변경에 대한 이벤트 Listening  

  2) install file:c:/temp/testbundle.jar 파일 명령 : INSTALLED 상태가 된다
번들의 manifest 오류들을 점검 한다 

  3) resolve <bundle number> : RESOLVED 상태가 된다 
번들의 Export / Import를 연결해 주는 단계,  resolving 상태에서 문제가 발생하면 diag 명령을 내려서 원인을 찾는다

  4) start <bundle number> : STARTING->ACTIVE 상태가 된다
BundleActivator.start(BundleContext)가 호출된다. 문제 발생시 다시 RESOLVED 상태로 돌아 간다
start 안에는 많은 시간이 소요되는 작업을 해서는 안되고 있다면 별도의 스레드로 진행한다 

  5) stop <bundle number> : STOPPING->RESOLVED 상태가 된다
BundleActivator.stop(BundleContext)가 호출된다. stop()을 호출하면 만들어 놓은 스레드나 서비스를 종료 해지해야 한다. 따라서 stop 호출시 사용한 스레드, 서비스들을 종료하는 코드를 넣는다.   

  6) uninstall <bundle number> : RESOLVED-> UNINSTALLED 상태가 되고 ss(Equinox 기준) 또는 lb (felix 기준) 명령으로 보면 bundle 명칭이 나오지 않는다. 번들이 삭제된 것임 
번들이 완전 제거 되는 것임. OSGi 목록에서 나타나지 않는다 

OSGi 번들은 jar 파일로 패키징이 되고 안에 META-INF/manifest.mf 파일이 존재해야 한다. 해당 파일에는 번들의 명칭, 버전, 의존관계, 정책등이 기술된다. manifest.mf 파일 만들기는 OSGi Layer에서 Module Layer의 모듈 즉, 번들을 만들기 위한 중요 부분이다.

Name: Value 방식으로 서술이 된다. 

일반적인 기술 방법은 http://blog.naver.com/PostView.nhn?blogId=kittenjun&logNo=10126086035 사이트를 참조한다. 

중요하게 생각되는 항목은

  - BundleActivator를 상속받아 구현한 클래스 지정하는 Bundle-Activator

  - OSGi에 노출되는 외부명칭 Bundle-Name, 내부 키명칭 Bundle-SymbolicName

  - 번들 버전 Bundle-Version 

  - 외부 Bundle을 사용한다면 Import-Package

OSGi 프레임워크중 r4를 구현한 Felix를 설치하고 간단히 구현한 번들을 어떻게 올려서 사용할 수 있는지 보자. 

▶ 테스트 환경

  - Felix를 local PC에 설치하고 구동한다  (Felix가 OSGi 프레임워크라고 하지만 사실은 기능이 아무것도 없고 필요한 기능을 구현한 번들을 운영 관리해 주는 미들웨어-Middelware-라고 보면 된다)

  - Jetty 엔진 번들을 Felix 프레임워크에 올린다(start). 

  - Test용 Http Servlet 호출 프로그램을 짜고 번들로 만든다 (TestServlet 번들)

  - TestServlet 번들을 Felix에 올린다(start)

  - 브라우져에서 TestServlet을 호출해 본다. 

  1) Felix (http://felix.apache.org/site/downloads.cgi) 에서 main framework 을 다운로드 한다

  2) 다운로드 zip 파일을 적당 위치에 푼다 (이전에 JDK 설치는 필수)
   

  3) 디렉토리 위치에 felix.bat 파일을 만든다  (bat 내용 :  java -classpath ./bin/felix.jar org.apache.felix.main.Main )    

  4) cmd 창을 띄워서 felix.bat 을 실행하고, lb 명령을 수행하면 현재 기본 Activate된 번들 정보가 나온다 (help 다른명령보기)

  5) felix에는 shell과 repository 번들이 bundle 디렉토리에 존재한다.

  6) 다른 번들을 auto deploy하기 위하여 conf/config.properties에서 #felix.auto.deploy.dir=bundle 로 되어있는 주석 #을 제거한다. 그리고 bundle디렉토리에 다운로드 받은 번들 jar 파일을 놓고 felix를 재시작하면 자동 activate된다.

  7) 수동 active 방법 : install xxx.jar   -->  start <번들No.> 

  8) felix를 일단 시작하면 기존 active된 상태 정보들은 felix-cache디렉토리에 영구저장된다. (번들 activate 상태정보를 완전 제거하고, felix를 초기화 하고 싶다면 해당 디렉토리를 삭제하면 된다)

  9) http://felix.apache.org/site/downloads.cgi 사이트에서 HTTP 관련 subproject 번들을 다운로드 받아서 로컬의 <felix 홈>/bundle 디렉토리에 copy한다


  

  10) felix를 재시작하면 jetty가 8080 port로 Listening을 한다 (포트 변경은 jetty bundle 압축을 풀고, metatype.xml 에 정의된 port 수정후 재 배포한다

  11) http://localhost:8080/ 을 호출해 보면 jetty 404 에러가 보이면 정상이다. (왜? 아무런 서비스도 올리지 않고 단지 jetty servlet engine만 기동 되었기 때문이다)
 

  12) 테스트 번들 만들기는 다음 블로그에서 소개하기로 하고 첨부된 httptest.jar 를 특정 디렉토리에 복사한다. 

  13) felix 위에 activate 시켜보자. 여기선 bundle 디렉토리에 파일을 놓고 felix를 restart함으로써 auto deploy 말고 수동으로 바로 activate 시켜본다 ( felix:install file:<directory> , 주의 : 윈도우 구분자는 \\ 두개 삽입하고 전체경로 지정 )

  14) http://localhost:8080/servlet1/MyMusicCollection  을 호출한다

  15) counting crows 입력값을 넣고 submit 하면 jetty가 해당 요청을 받아서 test servlet으로 요청처리를 보내고 결과를 반환한다

▶ OSGi (Open Services Gateway Initiative)

OSGi 기술은 java에서 동적 컴포넌트 시스템을 정의한 스펙이다. 

The OSGi technology is a set of specifications that define a dynamic component system for Java. 

컴포넌트 모듈을 만들고 이들을 추가하면 동적으로 반영되고 상호 모듈끼리 통신하여 대화할 수 있도록 만들어 주는 부분이 필요하다. 이를 위하여 OSGi는 어떤 Layer를 가지고 있나 보자 

참조 http://www.osgi.org/Technology/WhatIsOSGi

위의 관계를 간단히 보면 다음과 같다

  - 자바 인터페이스와 실제 구현 개체를 Service로 만든다 - Services Layer

  - 서비스를 제공하기 위한 기능적 배포단위로 Bundle을 만든다 (Jar 파일롤 묶음. MANIFEST 파일 포함) - Module Layer

  - 번들의 생명주기 관리는 Bundle Context가 해준다 (번들의 설치, 실행, 정지, 삭제 생명주기관리) - Life Cycle Layer

  - Installed -> Resolved -> Start -> Active -> Stop -> Resolved -> Uninstalled 

  - 개발자입장에서 큰규모의 분산환경 구현 및 배포를 컴포넌트 기반으로 하기 때문에 이에대한 복잡성을 제거하여 단순화 해준다. (Eclipse, JBoss, Spring등에 쓰이고 있다)

  - 사업면에서는 운영비용을 줄여주고 네트워크환경의 멀티디바이스 통합을 손쉽게 해준다 

  - 또다른 이점은  http://www.osgi.org/Technology/WhyOSGi 여길 참조하자. 좋은 점은 다가졌다는 이야기

하이퍼소닉은 애플리케이션 테스트용으로 사용하는 것으로 실 운영시에는 적은 메모리라도 아끼기 위하여 삭제하는 것이 좋다. 하이퍼소닉은 외부 접근이 안되므로 보안에 대한  설정은 없지만 운영들어 가기전에 삭제한다

• deploy> 밑에서 ls *ds.xml 검색하면 hsqldb-ds.xml 파일이 나온다 
• hsqldb-ds.xml 파일을 삭제한다 

• deploy 밑에 oracle-ds.xml 파일을 만든다 
• DefaultDS를 사용하고 있는 ejb2-timer-service.xml의 설정을 oracle로 변경한다
• JMS를 사용하면 deploy/messaging/hsqldb-persistence-service.xml 파일을 지우고 동일한 oracle-persistence-service.xml 파일을 만든다
• uuid-key-generator.sar에서 UUID 키 생성을 한다면 META-INF/jboss-service.xml 에서 DefaultDS를 변경한다 

Java Messaging Service를 사용하지 않는 다면 다음의 파일 또는 내용을 제거 하여 자원(메모리, CPU) 소모를 예방한다

• deploy/messaging 디렉토리 삭제
• deploy/jms-ra.rar 파일 삭제
• deployers/messaging-definitions-jboss-beans.xml 파일 삭제
• conf/standardjboss.xml 파일에서 jms 관련 내용 제거 

• deploy/messaging/destinations-service.xml 안에 <security>를 설정한다
• conf/login-config.xml 파일에 <application-policy name="JMSRealm"> 이라는 새로운 application 정책을 만든다 
• 마지막으로 deploy/messaging/messaging-jboss-beans.xml 안에 <bean name="SecurityStore">를 설정한다 

▶ shutdown이나 twiddle이 JBoss의 내부 마이크로 커널과 통신하려면 JMX invoker를 사용한다.

• deploy/jmx-invoker-service.xml 구성에서 org.jboss.invocation.Invocation 에 대한 인증 인터셉터를 추가한다

• jnp 프로토콜 접속하는 JBoss 설치 IP (옵션)
• -u 인증 admin 아이디 
• -p admin 계정의 패스워드 

▶ HTTP Invoker 는 80 포트를 통해서 외부세계에서 JBoss의 JNDI, JMX invocation, EJB invocation등의 원격 접속을 허용한다. 

• 80 포트는 애플리케이션을 요청하는 포트 이므로 HTTP Invoker는 아예 삭제를 한다
• deploy/http-invoker.sar라는 단일 서비스를 디렉토리 몽땅 제거하면 서비스가 삭제된다

JBoss 5.x에 대한 관리화면 폴더는 각 도메인안의 

• deploy/jmx-console.war : JMX 콘솔
• deploy/management : 웹 콘솔

• jmx-console.war/WEB-INF/web.xml에서 하기 security 테그의 주석을 제거한다 

• JBossAdmin 권한을 가진 사용자만이 JMX 콘솔 사용이 가능하다 
• 사전에 WEB-INF/jboss-web.xml 의 보안 도메인 링크가 하기와 같이 설정되어 있어야 한다

• security domain에 대한 부분은 conf/login-config.xml에 하기와 같이 설정되어 있다

• conf/props 디렉토리 밑에 jmx-console-users.properties에 key=value로 admin을 정의 한다
• conf/props 디렉토리 밑에 jmx-console-roles.propertiess에 하기와 같이 역할을 정의 한다

• management/console-mgr.sar/web-console.war/WEB-INF 디렉토리에서 web.xml 의 security 태그 주석을 제거하고 jboss-web.xml에서 java:/jaas/web-console를 java:/jaas/jmx-console 로 변경하면 똑같은 보안설정을 따르게 된다. 

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Listener refused the connection with the following error:

ORA-12505, TNS:listener does not currently know of SID given in connect descriptor

 )

        at org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:1549)

        at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1388)

        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)

위와 같은 메세지가 나오면 다음과 같이 수정하여 Listener를 restart 시킨다. 

• ORA-12505, TNS:listener does not currently know of SID given in connect descriptor 이 메세지 구글링 해보면 lsnrctl services 수행해서 SID가 잘 나오는지 확인해 보라고 하는데 백날 해봐야 SID 안나오고 UNKNOWN 이라고 나온다. 
• 그럼 listener.ora 파일을 열어보자. 하기와 같이 나올 것이다. 

• 서비스에서 Listener를 restart 해보고, lsnrctl services 명령어 날려보자. 하기 빨간색 문구가 새롭게 나온다. 

JBoss의 사용하는 port를 변경하거나, 서비스 추가/삭제 및 환경설정에 대한 관리를 알아보자. 이런 관리를 위해서는 먼저 JBoss의 아키텍쳐를 아는 것이 중요하다. 

• 4.0.3 이전 JMX를 이용하여 service 추가/삭제
• 4.0.3 이후 microcontainer 상에서 service를 POJO(Plain Old Java Objects) 로 만들어 추가/삭제 가능
• 5.x 버전부터 JBoss는 microcontainer-based 아키텍쳐를 사용하고 있다. 

• Spring framework와 유사하게 dependency injection framework 이다 
• DI에는 다음과 같은 설정을 한다
• instantiated할 오브젝트 설정
• 인스턴스 오브젝트의 constructor 파라미터 제공
• set 프로퍼티에 값 설정
• 오브젝트끼리 의존관계 설정
• microcontainer는 이전의 JMX kernel 아키텍쳐보다  훨씬 가볍다, 환경설정이 적다, 서비스들을 standalone올 디플로이 할 수 있다. 
  
• microcontainer위에 모든 서비스가 올라간다 (단, v5.0에는 JMX kernel위에 JMX, JNDI등이 올라가지만 이후는 microcontainer위에 전분 올라가도록 변경됨)
• 환경파일의 이해
• server/xxx/conf/bootstrap.xml : primary beans configuration 파일이다 

• Client는 JMX Server를 통해서 xxxMBean 인터페이스를 상속받은 MBean 클래스의 내역을 서비스 받는다
  
• JMX Server가 xxxMBean을 lookup해서 찾고 client는 바로 xxxMBean을 접근할 수 없다. 
• jboss-service.xml 파일 설정을 기반으로 service deployer가 MBean을 인스턴스화 한다. 또한 *-service.xml 설정도 같이 엮어서 인스터스화 한다.
• jboss-service.xml 파일이 MBean 설정을 위한 primary descriptor 파일이다. 주 설정내역은 다음과 같다.
• logging service 
• thread pool : 다양한 서비스의 thread pool을 제공한다
• JNDI
• MBean 관리를 위한 security 
• MBean과 관련된 JMX 서비스들
• MBean과 관련된 remoting 서비스

• MBean 명칭안는 여러부분이 내포된다.
• domain : 자바의 패키지 명칭
• key-value : 콤마로 구분

예) jboss.jca:service=ManagedConnectionPool,name=DefaultDS

• jboss.jca = domain 이고 콜론앞의 값
• service=ManagedConnectionPool,name=DefaultDS = key properties들이고 콤마로 구분된다. (순서완 상관없음)

• bootstrap.xml : POJO를 초기화 하기위하여 microcontainer가 사용함
• jax-ws-catalog.xml : JAX-WS를 위한 맵핑에 사용함
• jbossjta-properties.xml : Java Transaction API (JTA) 서비스에서 사용함
• jboss-log4j.xml : 로깅 설정
• jboss-service.xml : JMX kernel에서 사용
• jndi.properties : JNDI 서비스에서 사용하는 디폴트 설정값
• login-config.xml : security 서비스에서 사용
• standardjboss.xml : EJB 서비스에서 사용
• standardjbosscmp-jdbc.cmp : Container Managed Persistence(CMP) EJB를 위한 다양한 DB 설정에 사용 
• 다른 환경 파일들 설명

JBoss는 메모리의 효율적 사용을 위하여 몇가지 종류의 서버 타입을 나누어 놓았다. 한번 들여다 보자 

▶ microcontainer 

• 메모리를 적게 사용한다
• 시작이 빠르다
• microcontainer 위에 필요한 서비스들이 plug-in 된다 
• server configureation은 같이 올라간다. 3종류 환경 : default, minimal, all

• default, minimal, all중 자신이 원하는 것을 하나 선택한다 
• Copy & Paste하고 디렉토리 명칭을 원하는 것으로 변경한다 

▶ Start / Stop 

다른곳에서 너무 잘 정리해서 그냥 참조 : http://www.allsoft.co.kr/bbs/board.php?bo_table=study97_1&wr_id=4

• 8080 가 default port로 사용
• 맨 끝에 Started in 시간 나오면 성공
• run.bat -c default -b <ip-address>

Mining 출판사에서 나온 내용을 읽으며 중요한 사항 및 참고할 만한 글을 올려 본다

• JBoss의 의미가 처음에는 Enterprise Java Beans Open Source Software 라는 뜻으로 EJBoss 였다가 E 자가 맘에 안들어서 JBoss가 되었단다
• JBoss 5 버전을 다운로드 받는 곳 :  http://www.jboss.org/jbossas/downloads
• 적당한 위치에 푼다 (5.1버전은 JDK6 사전설치)
• top level 디렉토리는 : bin, client, docs, lib, server 
• bin : run, shutdown, probe(discovering JBoss AS clusters)
• client : 클라이언트 어플리케이션과 통신을 위한 라이브러리들 존재
• docs : 메뉴얼, 샘플
• lib : core AS 라이브러리들 
• server : 특성에 맞는 운영을 위한 디렉토리로 구분  (conf / lib / deploy 는 공통으로 존재)