invalid-file

invalid-file

윈도우에서 로그를 자동으로 백업하기 위해 ANT를 사용하여

백업로직을 만들었습니다.

비교적 간단하게 작업이 되더군요.

작업순서는

1> 백업내역을 저장할 디렉토리 생성

2> 백업할 로그중 당일 분을 제외한 나머지를 JAR로 압축

    (매월 1일에 돌리면, 전월 분을 모두 백업할 수 있겠네요.)

    ----> 윈도우에서는 제어판->예약된 작업을 클릭하신후 작업을 추가하시면 됩니다.

             (매월 1일로 해야 겠지요)

3> 백업한 로그의 원본을 삭제

의 흐름으로 진행됩니다.

실행은 ant -buildfile logbackup.xml 로 하시면 됩니다.

!!!! 주의할 점은 그냥 돌리시면 로그가 삭제되므로 조심하셔야 합니다. !!!!!

※ 네이버 블로그의 파일첨부 로직으로 인해 dolbyman이 붙어 있으니

    dolbyman은 삭제하신 후 돌리시기 바랍니다.

Eclipse와 Jeus서버간의 디버깅

invalid-file

invalid-file

Remote Debug

개요

설명

디버깅 절차

환경설정

  -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Jboss

  set JAVA_OPTS=-Xdebug 
  -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n 
  %JAVA_OPTS%

JEUS

  -Xdebug -Xnoagent 
  -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n 
  -server

Weblogic

  set JAVA_OPTS= -Xdebug -Xnoagent 
  -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n 
  %JAVA_OPTS%

사용법

0. 지혜롭게 살자
많은 개발자가 전통적(?)인 방법인 System.out....로 디버깅을 많이 하고 있다. 물론 이것처럼 확실한 방법도 없지만 eclipse나 다른 IDE의 디버그 기능을 이용하면 훨씬 빨리 문제를 찾을 수 있다.
특히 WAS에 배포된 환경에서 이런 방법으로 하려면 확인하기 위한 System.out...을 고칠 때마다 배포해야 하는데 이건 너무 고통스러운 작업이다.

단위 테스트시 에러가 발생했을 때는 eclipse등을 이용해서 디버깅하기가 수월하다.
그러나 WAS에 배포된 후에 에러가 발생했을 때는 약간의 작업이 필요하다. WAS를 eclipse에 embeded한 플러그인을 이용하는 방법도 있지만 WAS와 이클립스를 따로 띄워 원격으로 버그를 찾는 방법을 정리한다.
이럴 경우 서버환경에서 돌아가는 자바 코드의 문제점도 쉽게 잡을 수 있다. (물론 절대! 운영서버에서 하면 안되겠지만)

여기서는 tomcat 6와 eclipse 3.3 그리고 java6 환경을 가정하고 설명한다. (그 하위 버전도 방법은 동일하다)

1. 문제지점 찾기
WAS에서 애플리케이션을 배포하고 돌려보니 에러가 발생하고 아래와 같은 예외스택을 출력했다.

이걸보면 JDBCCredentialsSPI.java 소스의 32 라인에서 null 객체를 참조하여 뭔가를 했다는 것을 짐작할 수 있다. 그럼 그 소스를 볼까?

아~ 한 줄에 많은 것들이 있네 ㅠㅠ. 이중 어떤 객체가 null 인지 알 수가 있나. 좀 고생하겠는데...

2. 디버깅을 걸자 (가장 중요)
다음과 같은 JVM 옵션을 사용하면 JVM을 기동할 때 디버그 모드로 기동되고 원격에서 그 디버그 세션으로 접속할 수 있다.

이는 8000 소켓으로 디버그 세션을 열어두겠다는 뜻이다.

내 경우 Tomcat을 사용하기에 다음과 같이 JAVA_OPTS의 환경변수에 저 옵션을 설정했다. Tomcat은 JAVA_OPTS 환경변수를 이용하여 JVM을 기동한다.

시작쯤에 다음과 같은 라인이 출력되면서 기동되면 성공한 것이다.

각 WAS에 -Xdebug ... 옵션을 설정하는 것은 조금씩 다르다. 각 WAS의 shell 스크립트를 살펴보고 적당한 환경변수를 주거나 직접 java 실행하는 부분에서 저 옵션을 추가하면 된다.
참고로 Maven 2로 개발할 경우 mvn jetty:run으로 WAS를 띄울 경우가 있는데 이런 경우는 다음과 같은 환경변수를 설정하고 띄우면 된다.

3. JVM 디버깅 세션에 연결
이클립스에서 디버깅 세션을 열기 위해서는 다음 단계를 따라하면 된다. 물론 디버깅하기 위한 소스는 이클립스 프로젝트에 있다고 가정한다. 프로젝트를 선택한 상태에서 디버그를 시작하는 것을 있지 말라.

"Run > Open Debug Dialog..." 메뉴를 선택하면 아래와 같은 Debug 다이얼로그가 나타난다.

Debuging

 Windows > Open Perspective > Other...

툴바에서 아래의 이미지가 이미 나와 있다면 그냥 클릭하여 사용할 수 있다.

Debug view

위에 그림과 같이 디버그를 실행하면 아래의 그림과 같이 디버그 화면이 나온다.

이때 원하는 디버그를 하나 클릭하면 빨간 테두리 안에 있는 것들이 활성화 된다.

Variables view

variables를 선택하면 해당하는 부분의 사이즈나 값등의 정보를 볼 수 있다.

Breakpoints view

이 리스트에서 모든 작업 중인 프로젝트의  break point를 볼 수 있다.

이것으로 break point를 지우거나 새로운 것을 추가 할 수 있거나 할 수 없다.

또한 더블 클릭하면 에디터로 갈 수 있다.

이것은 exceptions을 추가 또는 삭제 가능하다.

Expressions view

각각의 클래스로부터 suspended thread와 다른 지역에서 이것을 보고 검사할 수 있다.
Item이 view에 추가될때 자동적으로 오픈된다

Debug a web project

http://www.laliluna.de/assets/tutorials/java-servlets-jsp-tutorial.zip

사이트에서 어떻게 디버깅하는지에 대해 다운 받을 수 있다.

아래의 그림과 같이 오른쪽을 더블클릭하면 파란 동그라미가 생기고 그 부분부터 디버깅이 된다.

Note: If you don't have installed MyEclipse, you can't set a breakpoint in jsp and included

 files.

Breakpoint Properties

생성된 파란 동그라미를 마우스 오른 버튼을 눌러 아래와 같이 Breakpoint Properties 을

선택한다.

Hit Count

The hit count sets a number of times the breakpoint can be executed before the thread

suspends. Very helpful in a loop expression or if you want to know the value of a expression

after some hits.

Enable Condition

There are two options to suspend a thread by using a condition.

• if the enabled condition is true

• if the enabled condition changes

If you want that the condition suspends the thread when it is true select the option condition

is true on Suspend when.

Example:

action.equals("edit");

If you want that the condition suspends the thread when the value of the condition changes

select the option value of the condition changes on Suspend when.

Suspend Policy

You can define if the breakpoint suspends only the thread or the complete virtual machine.

Deploy and Debug

Now we want to debug the project, so deploy it and call it in your web browser.
Choose Edit on the list of books.

After you clicked the Edit link, eclipse shows you the following confirm window. You can

choose if you want to switch to the debug perspective. Yes, you want it ;- )

The first entry in the debug view represents the state of the method where the breakpoint was

 set. You can preview the state of a entry simply by clicking on it, also the file will be open

where the method is placed.

You can see the values of all variables of the selected entry in the Variables view.

A marked line and an arrow at the breakpoint shows that the debugger is suspended on this

 line.

If you've decided that you missed an important place in the execution process, perhaps the

breakpoint was in the wrong place, or maybe you accidentally stepped over some code you

wanted to inspect earlier in the process. Eclipse has a feature called Drop to frame, that

essentially lets you 'rewind' the execution to the beginning of any method in the stack. This is

especially useful when you perform variable modification or code hot swapping.
Right click on the frame and choose the option Drop to Frame.

Inspect expressions

To get informations about expression, you can inspect a expression. Right click on the marked

expression, you want to inspect and choose Inspect or press Ctrl + Shift + I. A pop-up

window appears that holds the informations about the expression.

Watch expressions

Watch is similar to inspect an expression. Watch means that the expression will be added to

 the Expressions view, where you can watch the informations about the expression. Add two

 expressions to the Expressions view.

Mark the expressions, right click and choose Watch.

Now the two expression are in the Expressions view.

Display expressions

If you want to display the type and the value of an expression, mark the expression and choose the Display option from the context menu (right mouse button) or press Ctrl + Shift +

 D.

Run to Line

If you set a breakpoint and somewhere under the breakpoint is a line you want to go, you can use the option Run to Line. The code between the breakpoint and the selected line will be

executed. Select the line you want to go, press the right mouse button and choose the option

 Run to Line or use the key binding Ctrl + R.

Debugging JSP files (supported by MyEclipse)

Debugging a JSP file is the same like debugging a Java class, but the most features (Watch,

Inspect, etc) are not implemented. The only way to get the values of variables is the Variables

view.

[출처] http://www.laliluna.de (랠리루나)

<script type="text/javascript">
<!--
        // HTML 페이지에 디버그 컨트롤 삽입
        function SetDebugMode()
        {
                var iDebug = "<OBJECT id=idbg classid='clsid:A7E78F01-4566-4A90-87EC-01EEF2D1344A'><param name='header' value='::'></<param name='UseDialogBox' value=false></OBJECT>";
                document.writeln(iDebug);
        }
 
        SetDebugMode();
 
        // 디버그 컨트롤 설치 여부 검사
        function Installed_iDebugX()
        {
                try
                {
                        return (typeof(document.all("idbg"))!="undefined" & document.all("idbg").object != null & idbg.installed());
                }
                catch(e)
                {
                }
        }

        // 디버그 메시지 출력
        function OutputDebugString(msg)
        {
                if (Installed_iDebugX())
                        idbg.OutputDebugString(msg);
        }
 
        // 디버그 메시지 대화상자 표시
        function ShowDebugString(msg)
        {
                        if (Installed_iDebugX())
                                idbg.ShowDebugString(msg);
        }
</script>
-->

<SCRIPT language='javascript' type='text/javascript' src='./debug.js'></SCRIPT>
<SCRIPT language='javascript'>
        ....
        ....
    OutputDebugString("변수 user_id:" + user_id);
        ....
        ....
</SCRIPT>
</HTML>

JEUS (Java Enterprise User Solution)는 인터넷으로 각광 받고 있는 Java를 기반으로 한 웹 솔루션으로, 웹 환경에서 어플리케이션을 운용하는 데 필요한 각종 서비스들을 제공해 주는 웹 어플리케이션 서버이다.

JEUS는 어플리케이션을 개발하고 실행할 수 있는 플랫폼 역할을 하면서, 트랜잭션 관리, 세션 유지, 부하 분산 등 다양한 기능을 제공할 뿐만 아니라, 계층화된 구조로 유연성과 기능 확장성이 우수해 비즈니스 로직을 손쉽고 효과적으로 구현할 수 있게 한다.

JEUS를 최초 설치하면 설치 시 지정된 디렉토리(JEUS_HOME)에 다음과 같은 디렉토리가 생긴다.

각각의 디렉토리에 대한 설명은 다음에 계속한다.

JEUS의 실행, 모니터링 등 JEUS의 운영에 관련된 스크립트 파일이 존재한다. Windows의 경우에는 batch파일로 있으며, UNIX의 경우에는 shell script파일로 되어 있다. 여기 있는 파일들 중 jeus.properties.bat(UNIX의 경우: jeus.properties)가 있는데 이 파일에는 JEUS실행에 필요한 각종 환경변수들이 설정되어 있다. 이를 제외한 나머지 실행파일들은 실행전에 항상 이 파일을 호출하여 환경변수를 적용하게 되어 있으므로 환경 변수의 수정이 필요한 경우에는 이 파일의 내용을 수정하면 된다.

EJB 등을 사용할 경우 client에서 사용하게 될 client모듈 등이 들어가게 되는 디렉토리이다. 일반적인 경우 잘 사용하지 않는다.

운영시 사용하게 되는 모든 설정 파일들이 들어있는 디렉토리이다. 하위 디렉토리로 dtds디렉토리는 JEUS설정 파일의 모든 xml에 대한 구조(dtd)를 가지고 있는 디렉토리이고, hostname으로 되어 있는 디렉토리에 현재 운영과 관련된 모든 설정을 가지고 있다.

이 디렉토리는 운영과 관련된 library들이 들어 있다. 아래에는 다음과 같이 3개의 디렉토리가 있다.

-          application: 개발시 필요한 library들을 넣어두는 디렉토리이다. Jar/zip형태의 파일을 넣어도 되고, package형태로 풀어놓아도 된다.

-          datasource: 이 디렉토리는 JDBC나 혹은 각종 connector를 위한 library를 넣어두는 디렉토리이다. Jar/zip형태의 파일만 인식한다.

-          system: 이 디렉토리는 JEUS의 엔진과 관련된 library들이 들어 있다.

위의 디렉토리들 중 개발 혹은 운영 시 필요한 라이브러리들은 application/datasource에 넣어두면 된다. System의 경우는 JEUS에서 사용하는 곳이므로 되도록이면 다른 파일들을 넣지 않는 것이 좋다.

라이센스가 들어가는 디렉토리이다. 최초 설치시(JEUS 4.2부터) 3개월간 사용할 수 있는 데모라이센스가 들어가 있다. 라이센스 파일은 license이다.

JEUS 운영 시 남게 되는 각종 로그 파일이 쌓이게 되는 디렉토리이다. JEUS운영환경의 설정에 따라 내부에는 디렉토리나 파일들이 naming rule에 따라 만들어지게 된다.

각종 예제 프로그램들이 목록에 따라 들어가 있는 디렉토리이다.

최초 설치시 각종 샘플과 같은 각종 application들이 들어가 있는 디렉토리이다. 하위 디렉토리는 다음과 같은 것이 이다.

-          admin_home: browser를 이용해 JEUS를 제어하고자 할 때 필요한 프로그램들이 들어 있다. 이는 JEUS에서 사용하는 디렉토리이므로 건드리지 않는 것이 좋다.

-          ejb_home: EJB에 필요한 jar파일이나 class가 들어가는 디렉토리이다.

-          servlet_home: WEB application이 들어가는 디렉토리이다.

-          ear_home: EAR application들이 들어가는 디렉토리이다.

이러한 디렉토리들은 유저의 필요에 따라(admin_home제외) 변경을 할 수 있다. 변경을 하고자 한다면 $JEUS_HOME/bin/jeus.properties.bat파일을 열어 관련된 환경변수를 수정하면 된다.

JEUS에 기본적으로 포함되어 있는 Web Server(WebtoB light)가 들어 있는 디렉토리이다.

JEUS가 운영 시 내부적으로 사용하는 임시 디렉토리이다.

JEUS는 크게 두 가지 형태의 process로 운영된다고 볼 수 있다.

하나는 manager process이고 나머지 하나는 container process이다.

첫째로 manager process는 container process를 관리하는 역할과 clustering환경 구성 시 JEUS 상호간에 필요한 정보들을 주고 받는 process로 개발 후 만들어진 각종 application과는 직접적인 연관이 없다.

두 번째로 container프로세스는 개발자에 의해 개발된 application을 실행시켜 주는 process이다.

이러한 구조를 그림으로 나타내면 다음과 같다.

위 그림에서처럼 manager process는 자신에게 포함된 container들을 관리하는 역할과 물리적으로 떨어져 있는 서버의 또 다른 manager process와 통신을 하면서 clustering환경을 유지하는 역할을 하게 된다.

Container process는 하나의 서버에 여러 개가 존재할 수 있다. 또한 container process는 여러 개의 engine을 포함하게 된다. 이러한 engine이 개발된 application 중 자신에게 해당하는 application을 실행시켜주게 된다. 예를 든다면 EJB engine은 EJB프로그램을 Servlet engine은 WEB application을 실행하게 되는 것이다. 이러한 container process는 하나의 독립적인 process로 동작하게 된다.

앞에서 JEUS의 모든 설정 파일은 $JEUS_HOME/config 디렉토리에 존재한다고 했었다. Config 디렉토리의 구조를 살펴보면 다음과 같다. 아래 그림은 최초 설치 시 만들어져 있는 디렉토리이다.

앞에서도 간단히 설명을 했듯이 dtds 디렉토리는 xml과 관련된 dtd파일이 들어 있는 곳이고, security 디렉토리는 JEUS운영 시 사용하게 되는 policy파일이 들어 있는 디렉토리이다.

나머지 hostname(그림에서는 ybsong_note)으로 되어 있는 디렉토리인데, 현재 JEUS가 설치된 서버의 운영과 관련된 모든 설정들은 이 디렉토리에 들어 있다.

가장 먼저 살펴볼 파일은 hostname 디렉토리에 들어 있는 JEUSMain.xml파일이다.

참고로 운영을 위해 각종 설정 파일을 생성할 때 먼저 JEUSMain.xml파일을 만들게 되고, 이 파일의 구성에 따라 부수적으로 필요한 설정 파일을 만들어 설정을 하게 된다.

JEUS에서 가장 중요한 설정 파일로 가장 기본이 되는 설정으로 manager프로세스에 대한 설정이라고 보면 된다. 여기에는 어떠한 container프로세스가 있는지 또 container에는 어떠한 engine이 들어 있는지에 대한 설정이 포함되어 있다. JEUS구동 시에도 가장 먼저 이 파일을 읽어 들인 후 설정에 따라 필요한 container process를 실행시킨다고 생각하면 쉽게 이해될 것이다.

아래는 최초 설정 시 들어 있는 JEUSMain.xml 파일이다.

아래에 중요한 몇 개의 tag에 대해 설명하였다.

-          node: 하나의 서버를 의미한다. 물리적인 하나의 서버를 의미한다고 봐도 무방하다. 내부에 engine-container tag를 포함하고 있다.

-          engine-container: 앞에서 설명한 container process를 의미한다. 여러 개를 가질 수 있으며 이는 여러 개의 container프로세스가 운영될 수 있음을 의미한다.

-          engine-command: 이는 앞에서 언급된 engine을 의미한다. Type에 따른 하는 운영되는 application의 형태가 달라지게 된다.

위의 tag중 engine-container와 engine-command를 적절히 조합하여 필요한 만큼의 container process와 engine을 생성하면 된다. JEUSMain.xml의 설정이 끝났다면 이젠 여기서 설정된 engine들에 대한 설정이 필요하게 된다.

참고로 Container process에 대한 설정은 필요하지 않다. 이유는 Container process가 application을 운영하는 기본 단위가 아니고 engine이 기본 단위이므로 이들에 대한 설정만을 필요로 한다. 다시 말하면, container process는 말 그대로 하나의 process의 단위이며 engine을 묶어주는 그룹의 개념만을 지니고 있으므로 JEUSMain.xml의 내용만으로 더 이상의 설정은 필요 없는 것이다.

JEUSMain.xml에 대한 자세한 설정은 JEUS Server 매뉴얼을 참조하면 된다.

Engine의 설정 파일은 engine의 이름으로 된 디렉토리 아래에 존재하게 된다. Engine의 이름을 붙이는 방법은 JEUS의 내부의 naming rule로 다음과 같이 JEUSMain.xml파일의 내용을 가지고 만들어지게 된다.

[hostname]_[engine tag의 type]_[engine tag의 name]

앞에서 보여진 JEUSMain.xml파일을 참고하면 다음과 같이 두 개의 engine이름이 존재하게 되는 것이다.

-          ybsong_note_ejb_engine1

-          ybsong_note_servlet_engine1

이렇게 engine의 이름을 만들었다면 이러한 엔진을 위한 설정파일이 들어가게 되는 디렉토리를 만들어야 한다. 그 디렉토리는 바로 JEUSMain.xml이 있는 디렉토리에 engine이름으로 디렉토리를 만들면 된다(앞에서 보인 config디렉토리의 구조에 관한 그림 참조).

각 engine에 대한 설정 파일들은 모두 자신의 이름으로 된 디렉토리 안에 존재하게 되는 것이다. 또한 각 engine마다 필요한 설정 파일은 engine의 type에 따라 달라지게 된다. Type은 세 가지가 있다. 아래에 type에 따른 설정 파일의 이름을 기술해 놓았다.

-          servlet type: WEBMain.xml

-          ejb type: EJBMain.xml

-          jms type: JMSMain.xml

이후에는 이들 중 가장 많이 사용하는 servlet과 ejb type의 설정 파일에 대해 살펴본다.

앞에서 봤듯이 servlet type engine의 주 설정 파일은 WEBMain.xml이다.

최초 설치 시 아래와 같은 설정 파일이 [hostname]_servlet_engine1 디렉토리에 들어 있다.

위의 파일 내용 중 몇 개의 tag만 아래에서 설명한다.

-          context-group: 이 tag는 context의 묶음을 의미한다. J2EE spec에서는 context에 대해서만 기술되어 있다. JEUS에서 context group의 개념을 사용하는 것은 세션 정보의 공유 등을 위해서 사용한다. 말 그대로 group의 개념이므로 내부에 context tag를 포함하고 있음을 알 수 있다. 참고로 context는 WEB application의 단위로 생각하면 쉽게 이해할 수 있다. group-docbase는 이 group이 물리적으로 존재하는 디스크 내 위치(디렉토리)를 의미한다.

-          context: WEB application의 단위이다. Context의 설정에 따라 이에 따른 deployment descriptor(DD)파일이 하나씩 더 존재하게 된다. 그 파일의 위치는 WEBMain.xml과 같은 위치이며 이름은 jeus-web-dd_[context_name].xml파일이다.

-          webserver-connection: servlet type의 engine은 WEB application을 처리하는 engine이므로 web server와의 연결을 담당하는 부분이 필요하게 된다. 이에 대한 설정을 하는 tag이다. 위에서는 http-listener만 되어 있지만, 이 외에도 webtob-listener/apache-listener 등이 올 수 있다.
http-listener는 다른 web server없이 JEUS자체적으로 HTTP를 받아들이고자 할 경우 사용하고, webtob-listener는 자체 web server인 WebtoB와, apache-listener는 Apache와의 연동을 위해 사용하면 된다.

아래에는 context마다 하나씩 존재하게 되는 DD파일을 표시하였다.

DD파일은 각각의 context에 대한 설정을 나타낸다. Context-name은 WEBMain.xml에 설정된 context-name을 의미하고, docbase는 디스크 상에서의 물리적인 위치다. Auto-reload는 운영 시 프로그램이 수정될 경우 이를 바로 반영할지에 대한 여부를 나타낸다.

그 외 자세한 내용들은 JEUS Web Container매뉴얼을 참조하면 된다.

EJB type engine의 주 설정 파일은 EJBMain.xml 파일이다.

최초 설치 시 포함된 EJBMain.xml파일은 다음과 같다.

위의 tag 중 module-list는 이 engine이 시작될 때 가지고 올라가야 할 EJB 모듈을 나열하는 tag이다.

EJB engine의 경우 위와 같이 간단하다. 이는 EJB의 경우 engine의 설정보다는 EJB를 구성하는데 필요한 ejb-jar.xml파일과 DD.xml에 많은 내용들이 기술되어 있기 때문이다. 이들에 대한 내용은 개발과 관련된 부분이므로 JEUS EJB 매뉴얼 혹은 개발자 교재를 참조하면 된다.

JEUS의 구동은 크게 두 가지 작업으로 나누어진다.

먼저 JEUS manager process(jeus명령어)를 구동한 후 jeusadmin tool을 이용해 manager에 접속한 boot명령을 이용해 부팅을 하게 된다.

Manager를 구동하면 다음과 같이 보여진다.

위와 같이 Ready 메시지가 나오면 manager가 구동된 것이다. 다른 command창을 열러 jeusadmin [hostname] 명령을 주어 manager에 아래와 같이 로그인 한 후 boot명령을 보내면 된다. ID/password를 물어보게 되는데, 최초 설치 시 ID는 administrator이며 password는 설치 시 입력한 값을 넣으면 된다.

위의 과정은 manager에 로그인 한 후 boot명령을 통해 JEUSMain.xml의 설정에 따라 container를 올리는 작업과 down명령을 통해 내리는 작업을 순차적으로 나열한 것이다.

jeusexit명령어는 앞에서 띄워놓은 manager를 종료시키는 작업을 수행한다. exit명령어는 jeusadmin tool을 빠져나가는 명령어이다.

이와 같은 과정을 거쳐 JEUS를 기동하고 내리는 작업을 완료하였다. 하지만 때에 따라서는 이러한 작업이 복잡하게 느껴질 수 있다. 편의를 위해 JEUS에서는 one-step으로 JEUS를 구동하고 종료할 수 있는 방법을 제공한다. 아래와 같은 방법을 통하면 그러한 작업을 쉽게 할 수 있다.

JManager는 GUI를 이용해 JEUS를 제어할 수 있도록 하는 tool이다. 실행하는 방법은 command창에서 jmanager라고 입력을 하면 된다. 이 tool을 이용해 부팅을 하기 위해서는 console을 이용할 때와 마찬가지로 jeus명령어를 이용해 manager process가 구동되어 있어야 한다.

JManager를 구동하면 가장 먼저 다음과 같이 ID/password를 물어보는 창이 보여진다.

로그인을 하면 다음과 같이 화면이 보여지게 된다.

위와 같이 화면이 나타나면 왼쪽 tree에서 hostname부분을 마우스 오른쪽 버튼을 눌러 나타나는 팝업 메뉴에서 boot를 선택하면 된다. 종료를 할 때에는 down을 선택하면 된다.

그 외 JManager에 대한 자세한 내용은 JEUS GUI 매뉴얼을 참조하면 된다.

WEB tool은 browser를 이용한 방법을 의미한다.

WEB tool을 사용하기 위해서는 먼저 JEUSMain.xml에 다음과 같이 설정이 되어 있어야 사용할 수 있다. JEUS 4.2의 경우 설치 시 기본적으로 설정되어 있으므로 따로 설정할 필요는 없다.

Console tool 혹은 JManager를 이용할 경우에는 jeus명령어를 통해 manager process만 기동되어 있으면 사용할 수 있었으나, WEB tool의 경우 boot명령까지 완료되어 있는 상태에서 사용할 수 있다. 이는 WEB tool이 내부적으로 servlet engine을 사용하기 때문이다. One-step 부팅을 이용하면 쉽게 사용할 수 있다.

먼저 부팅이 되어 있는 상태에서 다음과 같이 접속을 하면 ID/password를 물어보는데, 이후부터는 JManager와 비슷한 방법으로 사용을 하면 된다.

접속 URL: http://ip:9744/webadmin

IP는 JEUS가 설치된 서버의 ip를 말하며 9744는 default port이다. 이 값은 환경변수에 따라 달라지는데, 기본적으로 JEUS_BASEPORT + 8번의 값을 사용한다. JEUS_BASEPORT는 $JEUS_HOME/bin/jeus.properties.bat파일에 설정되어 있다.

최초 브라우저를 이용해 접속을 하면 다음과 같은 화면이 보여지게 된다.

ID/password를 입력한 후 로그인을 하면 다음과 같은 화면이 보여지게 된다.

이후부터는 직접 부팅과 다운 작업 및 설정의 변경, 모니터링과 같은 작업을 수행할 수 있다.

이는 3장에서 설명한 방법으로 직접 설정 파일을 편집하면 된다.

가장 먼저 편집해야 할 파일은 JEUSMain.xml 파일이다. 파일을 열어 engine-container tag를 하나 더 만들면 된다. 쉽게 작업을 하려면 기존에 있는 engine-container tag를 copy & paste한 후 필요한 부분들만 수정하면 된다. 수정이 필요한 부분은 engine-container/name tag의 name과 engine-command/name부분이다. 이를 수정하는 이유는 container의 이름과 engine의 이름이 중복되어 사용할 수 없기 때문이다.

JEUSMain.xml파일의 수정이 완료되었다면 그에 따라 engine의 설정 파일을 만들어 주어야 한다. 역시 3장에서 설명한 것처럼 engine의 이름에 따라 디렉토리를 만든 후 engine의 type에 따른 설정 파일(WEBMain.xml, EJBMain.xml 혹은 JMSMain.xml)을 만들어 준다. 역시 작업을 쉽게 하려면 기존에 있는 디렉토리 전체를 복사한 후 쉽게 각 설정 파일 중 필요한 부분만 수정을 하면 된다(ex: http-listener부분의 port와 같은 부분).