Tagged: java

web.xml 스키마 예제 헤더

web.xml 스키마 헤더 예제는 버전별로 다음과 같다.

Servlet 2.5

Servlet 3.0

Servlet 3.1

Servlet 4.0

Servlet 5.0

Servlet 6.0

참고: IBM Knowledge Center

Windows JDK 1.8 Portable

최근에(2017년 11월) JAVA 9 가 발표 되었다. 이와 관련해서 이미 JAVA 9로 많은 소프트웨어가 포팅되고 배포되고 있다. 대표적으로 자바 개발 도구인 이클립스의 경우 최신버전은 JAVA 9 에서 매우 잘 동작 한다.

하지만 여전히 많은 소프트웨어가 JAVA 8 을 필요로 한다. 한 시스템에서 JDK 를 두가지 버전을 설치하는게 썩 좋아보이지 않다. 시스템에서 JAVA 9 를 메인으로 하고 JAVA 8은 포터블하게 설치해서 사용하면 얼마나 좋을까?

이 문서는 Windows 에 JDK 1.8 을 포터블 제작에 대한 것이다.

환경

  • Windows 10 64bit
  • JDK 1.8 u152
  • 7-zip 64bit

JDK 1.8 의 포터블 제작을 위한 환경은 위와 같다. 압축 프로그램이면 아무거나 다 되는거 아니냐 하겠지만 7-Zip 을 권장 한다.

압축 해제

다운받은 JDK 1.8 u152 설치 파일을(exe) 오른쪽 클릭한 후에 압축 해제한다.

JDK 1.8 u152 압축해제

압축을 해제하고 나후 디렉토리를 펼치면 위와같이 나온다.

tools.zip 파일

포터블 JDK 의 핵심은 바로 tools.zip 이다. 이 파일에는 java 의 실행파일, 라이브러리 파일등이 들어 있다. 문제는 이 파일이 안보이는데, JAVA_CAB10 디렉토리에 111 파일이 보인다. 이 파일을 압축 해제한다.

tools.zip

위 파일을 압축 해제하면 드디어 익숙해 보이는 파일들이 보인다.

tools.zip 압축해제

문제는 이걸 그대로 사용할 수가 없다는 것이다. 이 안에 많은 파일들이 *.pack 인채다.  cmd 창에서 tools.zip 압축해제한 디렉토리로 이동한 후에 다음과 같이 해준다.

그러면 다음과 같이 pack 파일이 jar 파일로 변경된다.

pack 파일을 jar로 변환.

src.zip 파일

JDK 1.8 의 소스 파일인데, 이는 다음과 같이 110 파일을 압축 해제하면 된다.

src.zip 파일

src.zip 파일을 tools.zip 압축 해제했던 디렉토리에 넣어준다.

COPYRIGHT 파일

JDK 에 COPYRIGHT 파일이 있어야 한다. 이는 다음과 같은 디렉토리에 112 파일을 압축해제하면 나온다.

JDK 1.8 COPYRIGHT 파일

압축해제해 나온 COPYRIGHT 파일을 tools.zip 압축해제한 디렉토리에 넣는다.

JDK 1.8 Portable

tools.zip 압축해제하고 pack 파일을 jar 로 전환하고 src.zip, COPYRIGHT 파일을 작성해 tools 압축해제한 디렉토리로 옮겨놨다.

이제 이 tools 디렉토리를 JDK 1.8 로 바꾸고 적당한 디렉토리로 옮겨서 사용하면 된다.

JDK 1.8 Portable

 

참고

  • https://portableapps.com/node/53015
  • https://techtavern.wordpress.com/2014/03/25/portable-java-8-sdk-on-windows/

 

아주 심플한 자바 웹 애플리케이션

이중화 시스템을 구축하면 WAS 서버의 헬스 체킹을 하기 위한 웹애플리케이션 페이지가 필요할 때가 있다. AWS ELB 가 대표적으로 ELB 뒤에 WAS 서버가 있을 경우에 HTTP를 이용한 헬스 체킹을 위해 웹애플리케이션의 페이지가 필요하게 된다.

보통은 Product 웹프로그램에 AWS ELB 헬스체킹을 위한 페이지를 넣을 수도 있지만 별도의 웹애플리케이션을 작성하는게 더 좋다.

이 문서는 이러한 환경에서 헬스체킹을 위한 아주 심플한 자바 웹 애플리케이션을 작성하는 법에 대해서 기술 한다.

디렉토리 구조

기본적으로 웹 애플리케이션의 기본 디렉토리는 다음과 같다.

  • META-INF/MANIFEST.MF
  • index.jsp
  • WEB-INF/web.xml

위 디렉토리와 파일을  jar 를 이용해서 war 파일로 압축해 배포하면 된다. 이때 Context Root 는 war 파일 이름이 된다.

META-INF/MANIFEST.MF

위 파일은 war 파일의 정보를 기재하는 것으로 다음과 같다.

index.jsp

위 파일은 다들 알다 시피 html, jsp 문법을 쓸수 있는 파일이다. 그냥 OK 글자 하나만으로도 된다.

web.xml

이 파일은 웹애플리케이션 동작에 대해 설정하는 파일이다. 다음과 같다.

그냥 index.jsp 파일에 대해서만 설정 하면 된다.

healthcheck.war 만들기

위에서 기술한 디렉토리에서 다음과 같이 입력해 war 파일을 만든다.

이렇게 하면 war 파일이 나온다.

그리고 이것을 WAS 서버에 배포하고 브라우저에서 ‘http://server:8080/healthcheck/index.jsp’ 를 호출하면 OK 가 나온다.

AWS ELB 에서 HealthCheck 설정에서 port 는 8080, URL 은 /healthcheck/index.jsp 를 기재하면 WAS 에 대한 헬스체크를 HTTP를 통해서 할 수 있게 된다.

 

 

 

 

 

 

Tomcat 시작 스크립트 옵션들.

Tomcat 시작 스크립트에는 많은 옵션들이 있는데, 이에 대해서 기술합니다.

start.sh 스크립트

Tomcat 을 시작하기 위해서는 CATALINA_HOME/bin/startup.sh 파일을 실행하면 된다. 이 스크립트 내용을 간단히 살펴보면 다음과 같다.

최종적으로 catalina.sh 파일을 호출하고 있는데, 이 파일에는 시작시에 사용할 수 있는 각종 쉘 환경 변수들이 나온다.

Catalina.sh 스크립트

CATALINA_HOME

Catalina 가 빌드된 디렉토리. 여기서 빌드된 디렉토리는 설치한 홈 디렉토리를 말하기도 한다.

CATALINA_BASE

Catalina 설치에 동적 영역을 해결하기 위한 기본 디렉토리. 이는 Multi Instance 설치할때에 에 사용된다. 만일 지정하지 않으면 CATALINA_HOME 을 사용한다.

CATALINA_OUT

stdout, stderr 를 어디로 보낼지에 대한 전체 경로를 지정. 기본 값은 $CATALINA_BASE/logs/catalina.out 이 된다.

CATALINA_TMPDIR

JVM 에서 사용할 (java.io.tmpdir) 의 임시 디렉토리 위치. 기본값은 $CATALINA_BASE/temp 이다.

CATALINA_OPTS

“start”, “run”또는 “debug”명령이 실행될 때 사용되는 Java 런타임 옵션. JAVA_OPTS 에 포함되는 옵션이 아닌것이 여기에 포함된다. Tomcat 자체에서만 사용되는 옵션들만 포함되며 중지 프로세스, 버전 명령 등으로는 사용해서는 안된다.

JAVA_HOME

JDK 설치한 위치. debug 인자와 실행할때 필요하다.

JRE_HOME

JRE 설치한 위치. 지정하지 않으면 JAVA_HOME 을 사용하고, JRE_HOME 과 JAVA_HOME 지정되면, JRE_HOME 를 사용한다.

JAVA_OPTS

명령이 실행될때 사용되는 Java 런타임 옵션. CATALINA_OPTS 모든 옵션이 아닌것이 여기에 포함된다. Tomcat 에의해서 사용되어질 수 있고 중지 프로세스, 버전 명령에도 사용된다. 대부분의 옵션들은 CATALINA_OPTS 에 있어야 한다.

CATALINA_PID

catalina 시작 java 프로세스의 pid 를 가지고 있는 파일 경로.

LOGGING_CONFIG

Tomcat의 로깅 설정 파일을 재정의. 예를들면 다음과 같이 한다.

LOGGING_MANAGER

Tomcat 의 로깅 메니저를 재정의. 예를들면 다음과 같이 한다.

 

CATALINA_OPTS, JAVA_OPTS 예제

여기서 중요한 CATALINA_OPTS, JAVA_OPTS 이다. 대부분 이를 구분하지 않는다. 하지만 설명에서 나왔듯이 구분해서 사용하는 것이 좋다. 예를들면 다음과 같다.

JAVA_OPTS 는 Tomcat 에서 사용되어질 변수들을 정의할 수 있다.

 

위와같이 구분을 해서 사용하는 것이 좋다.

Java 8 람다 표현식

이 글은 다음의 Youtube 강의 내용을 요약 정리한 것입니다.

  • Java 8 Lambda Basics – Java Brains

왜 람다(Lambda) 인가?

  • 함수형 프로그램이 가능하다.
  • 읽기 쉽고 간결한 코드
  • API 나 라이브러리 사용이 좀 더 쉽다.
  • 패러럴 프로그래밍이 가능하다.

람다는 함수 자체를 값으롤 할당할 수 있는 Inline 함수처럼 표현된다.

 

람다 표현식(Lambda Expressions)

자바에서 메소드로 불리우는 함수 표현식은 대략 다음과 같은 형식을 갖는다.

Inline Values

위 예제는 Inline Values 가 무엇인지 보여준다. 별다른 객체, 메소드의 도움이 바로 할당하는 형식이 바로 Inline Values 라고 보면 된다.

그렇다면 코드 블럭(Code Block) 자체를 인라인으로 할당 할 수 있지 않을까? 다음과 같이 말이다.

실제로 JavaScript 에서는 Inline 함수라고 해서 존재한다. 다음과 같은 형식을 갖는다.

Java 8 에서의 람다 표현식은 JavaScript 에서의 인라인 표기와 유사하다.

HelloWorld 람다

HelloWorld 를 통해서 람다 표현식을 익혀보자.

전형적인 HelloWorld 코드다. 이것을 람다 표현식으로 어떻게 바꿀까? 먼저 메소드 자체를 Inline Value 할당하듯이 가상의 변수에 할당해보자. 다음과 같이.

public 은 접근제한자라고 해서 protected, private 등이 있다. 변수에 할당하는 행위에서 있어서 이러한 접근제한자는 의미가 없다. OOP 에서는 객체의 변수를 직접 받는것이 아니라 메소드를 통해서 할당 받는데, 람다 표현식에서는 Inline Value 로 직접 할당하는 방식이기 때문에 무의미하다. 지우자!

코드를 다시보면 perform  이라는 함수 이름이 존재한다. 하지만 코드 블럭자체를 왼쪽 변수에 할당하고 그러한 코드 블럭은 왼쪽 aBlockOfCode 를 호출함으로써 동작하게 될터이다. 따라서 perform 이라는 함수 자체를 지칭하는 이름은 불 필요하다. 이는 앞서본 JavaScript 의 인라인함수 표현식에서처럼 할당되는 함수의 이름이 없는것과 같다. 지우자!

void 는 리턴타입을 말한다. 아무런 리턴도 없다는 의미이기도 하다. Java 8 컴파일러는 똑똑하다. 람다 표현식에서 리턴타입을 명시하지 않더라도 컴파일러가 알아서 해준다. 지우자!

다 됐다. Java 8 에서 람다 표현식에서는 ->  를 이용한다. 다음이 Java 8의 람다 표현식의 완성이다.

이게 정상적인 코드라구? 그렇다. Java 8 에 도입된 람다표현식이다. 정확하게 잘 동작한다. 위를 좀 더 간결하게 바꿔 쓸수도 있다.

 

람다(Lambda) 예제.

다음을 람다 표현식으로 바꿔보자.

Inline 변수 할당이기 때문에 객체 접근제한자는 필요가 없다. public 삭제..

Inline 변수 할당이기 때문에 double 이라는 함수자체이 이름도 필요가 없다. double 삭제.. 그러면 다음과 같은 형태만 남는다.

자바 컴파일러는 매우 똑똑하다. 리턴타입을 추론해 맞춰준다. 먼저 인자 타입이 int 형이라 결과도 나름대로 int 형일것으로 추정하기도 하고 리턴 되는 계산을 하면서 리턴타입을 추론하기도한다. 별도로 리턴타입을 정의해줄 필요가 없다. int 리턴타입 삭제…

그렇게 하고 나면 다음과 같이 람다 표현식을 쓸수 있게 된다.

람다 표현식이다. 하지만 이를 좀 더 줄이면 다음과 같이 쓸 수 있다.

한줄로 다 작성할 수가 있다면 {} 블럭을 사용할 필요가 없고 {} 없는 경우에 return 을 쓰지 않아도 된다.

모든 람다가 {} 이 필요 없는 것은 아니다. 다음과 같이 블럭내에 로직이 들어갈 경우에 {} 블럭과 return 이 필요하다.

문자열 길이를 알아내고자 한다면 어떻게 람다 표현식을 쓸 수 있나? 다음과 같다.

물론, 앞에서 처럼 뭔가 로직을 넣어야 한다면 {} 감싸고 return 을 해주면 된다.

WebLogic WLST 사용하기.

WebLogic 은 Administrator 를 위한 Web GUI 콘솔을 제공한다. 브라우저를 통해서 관리자로 로그인을 하면 Web 을 통해서 각종 설정들을 할 수 있게 된다.

하지만 Web 을 사용할 수 없는 환경이라면 무용지물이 된다. 이럴때 WebLogic Scripting Tools(WLST)를 사용하면 된다. 자바로 만들어지는 Tools 로서 Web GUI 화면 대신에 터미널상에서 실행되며 대화형식으로 Web GUI 콘솔에 모든 기능을 사용할 수 있다.

실행하기

실행은 먼저 WebLogic 서버의 전역 변수를 소스(Source) 함으로써 WLST 실행환경을 조성해 준다.

 

WLST 실행하기

이제 다음과 같이 WLST 을 실행한다.

이제부터는 대화형으로 명령어를 입력하고 결과를 받아보는 형식으로 진행이 된다. 위와같이 처음 접속을 하면 offline 으로 되는데 먼저 Admin 으로 로그인을 해보자. 이는 Web GUI 콘솔 로그인과 동일한 효과를 가지고 온다.

주의할것은 위 WLST 실행을 Admin 서버에서 했기때문에 URL 에는 127.0.0.1 로 접속한 것이다. URL 은 정확하게 Admin 서버에 주소와 포트를 입력해야 하며 Web GUI 로그인 하기 위한 계정을 입력하면 된다.

로그인을 하고 나면 이제 뭘해야할지 고민이 되는데, ls() 를 먼저 입력하면 Web Admin Console 의 내용이 텍스트로 화면에 뿌려진다.

자세히 보면 Linux 의 파일시스템을 보는듯한 느낌 그대로라는 걸 알게 된다. d 로 시작하는 것들은 마치 디렉토리처럼 생각하면 된다. 그 안에 뭔가 또 있다는 것이다. 그 안으로 들어갈려면 다음과 같이 하면 된다.

위와같이 서버 디렉토리에 들어가서 보면 등록된 서버들 목록을 볼수 있다. 각 서버의 설정값들이나 카테고리를 보고 싶다면? 그 서버로 들어가면 된다.

 

Mac 에서 JAVA_HOME 찾기

참조: http://stackoverflow.com/questions/6588390/where-is-java-home-on-osx-sierra-10-12-el-captain-10-11-yosemite-10-10

Mac 에는 여러버전의 Java 가 설치되어 있습니다. 그런데, 가끔씩 JAVA_HOME 이 어디인지를 알고 싶을때가 있습니다. 그럴때 다음과 같이 하면 알수 있습니다.

 

 

WebLogic 구동 시 /dev/random 블로킹 이슈 해결

WebLogic 10.3.6 을 설치할때에 관리 서버 1개와 매니지드 서버 1개를 생성하게 됩니다. 그런데, 서버 시작 스크립트에서 난수 관련된 것을 고치지 않으면 시작이 굉장히 오래 걸립니다.

이는 Unix 시스템의 경우에 /dev/random 을 사용하지 않고 /dev/./urandom 을 사용하기 때문입니다.

이를 해결하는 방법은 두가지 인데, 첫번째로는 Java 의 Security 부분을 바꿔 주는 겁니다. 그러면 Java 를 사용하는 모든 자바 프로그램에 다 적용 됩니다. 다음과 같이 해줍니다.

이렇게 해주고 서버를 재시작 하면 적용 됩니다.

두번째는 Java 애플리케이션을 실행할 때에 JVM Command Line 파라메터를 주는 겁니다. 다음과 같이 해줍니다.

위와같이 서버 시작 스크립트에 JAVA_OPTIONS 환경변수에 난수 장치를 지정해 줍니다.

WebLogic 10.3.6 설치하기

이 문서는 WebLogic 10.3.6 설치에 관한 문서 입니다.

이 시점에서 WebLogic 10.3.6 는 아주 오래된 버전이다. JDK 1.6 을 기반으로 하고 JEE 도 오래된 버전을 지원한다. 그런데도 간혹 프로젝트를 하다보면 이 버전을 사용하는 곳도 심심치 않아 경악할 때가 있다.

WebLogic 을 버전 업그레이드를 한다고 하려면 어짜피 오래된 버전에 관해서 조금 알아 둘 필요가 있고 WebLogic 의 기본 구성의 경우에는 버전에 크게 상관이 없는 경우도 있어 나름대로 의미가 있다.

설치

WebLogic 10.3.6 버전은 Oracle 홈페이지에서 다운로드 받을 수 있다.정확하게 말하면 WebLogic 10.3.6 버전중에 “Zip distribution with Oracle WebLogic Server only and intended for WebLogic Server” 에 대한 것이다.

Oracle WebLogic Server only
Oracle WebLogic Server only

위와 같이 파일을 다운로드 받습니다. 그리고 다음과 같이 압축을 해제해 줍니다.

그리고 다음과 같이 MW_HOME 환경변수를 세팅해줍니다.

그리고 다음과 같이 configure.sh 파일을 Bash 쉘에 문법에 맞게 고쳐줍니다.

그리고 이제 configure.sh 를 실행해 줍니다.

여기서 한가지 중요한 것이 있는데, commEnv.sh 를 살짝 수정해줘야 합니다. 이걸 수정하지 않으면 64bit 시스템의 라이브러리를 환경변수로 세팅하지 못합니다.

 

도메인 생성

도메인은 WebLogic 에서 서버를 묶어주는 하나의 단위라고 볼 수 있습니다. 서버의 묶이라고 할수도 있고 서비스를 위한 하나의 큰 아키텍쳐라고 볼 수도 있습니다.

이 도메인은 별도의 다른 일반계정에서 디렉토리를 생성해서 생성할 수 있습니다. 여기서는 다음과 같은 위치에 도메인을 생성할 것입니다.

그리고 앞에서 configure.sh 를 실행해 생성된 환경설정을 세팅하기위해서 다음과 같이 실행해 줍니다.

그리고 다음과 같이 도메인 생성을 위한 명령어를 다음과 같이 실행해 줍니다.

 

실패

이렇게 설치를 시도했지만 안됨. 되다가도 아무런 반응이 없고 config.xml 파일이 생성되지 않고 시작/중지 스크립트도 만들어지지 않음.

이 방법으로는 안될듯.. 최소 용량으로 어떻게 돌려보나 했는데 문제가 있어보임.