Tagged: java

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

이중화 시스템을 구축하면 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 을 해주면 된다.

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 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 파일이 생성되지 않고 시작/중지 스크립트도 만들어지지 않음.

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

 

Java 설치

이 글은 Java 를 리눅스에 설치하는 법을 다룹니다.  Java 는 JDK, JRE가 존재하는데 WAS 서버 운영을 위해서는 JDK를 설치하는게 여러모로 좋습니다.

다운로드

다운로드는 Oracle 홈페이지의 Java 페이지에서 받을 수 있습니다. 보시면 다양한 패키지를 제공하는데, 저는 64bit 리눅스 tar.gz 파일을 다운로드 받았습니다.

설치

tar.gz 파일을 다운로드 받았다면 설치는 압축을 해제하는 것으로 사실상 끝이 납니다.

설정하기

자바 설치가 끝났다면 이를 시스템이 인식할 수 있도록 설정해줍니다. 설정은 자바 홈 디렉토리, 패스, 클래스패스등을 입니다.

이를 매번 입력하기 보다는 /etc/profile 맨 아래에 적어주면 부팅할때마다 자동적으로 시스템 전체에 적용 됩니다.

 

Apache Tomcat JNDI 설정

Apache Tomcat 도 JNDI 설정을 할 수 있다. 특히나 데이터베이스 연결을 위해서 JNDI 설정을 사용할 수 있다. JNDI 를 사용하면 Web Application 내에서 데이터베이스 연결을 할 필요가 없이 네이밍(Naming) 을 호출함으로써 간단히 해결된다.

이 문서에서는 MySQL 을 위한 Apache Tomcat JNDI 설정 에 대한 것이다.

MySQL Connector/J 설치

JNDI 를 이용해서 MySQL 연결을 설정하기 위해서는 MySQL Connector/J 를 먼저 설치해줘야 한다. 이것은 MySQL 홈페이지에서 다운로드 가능한데 파일이 jar 확장자를 가진 하나의 파일이 필요하다. 이 파일을 Apache Tomcat 라이브러리 디렉토리에 복사해주면 끝난다.

Apache Tomcat JNDI 설정

MySQL Connector/J 를 설치했다면, 이제 Apache Tomcat JDNDI 설정을 해야 한다. 이는 Apache Tomcat 의 conf 디렉토리에 context.xml 파일을 다음과 같이 설정 한다. 이 설정을 위해서는 MySQL 연결 정보를 알고 있어야 한다.

이렇게 해주고 Web Application 에 web.xml 파일을 설정이 필요하다.

web.xml 설정

Java Web Application 에서는 web.xml 파일이 존재한다. 여기에 JNDI 을 인식시키기 위해서 다음과 같이 설정 해줘야 한다.

Spring Context 설정

Spring 을 사용한다면 다음과 같이 JNDI 를 호출 할 수 있다.

여기서 주의해야할 것은 jndiName 이 ‘comp/env/’ 를 덧붙인다는데 있다. 앞에 설정을 보면 ‘jdbc/MySQLDS’ 로만 설정 된되지만 Spring 에선 ‘comp/env/’ 를 앞에서 붙여주는 것이 다르다.