0705 - 0808

0706 - SpringBoot properties와 yaml

YAML (YML Ain't Markup Language)

• XML, C, 파이썬, 펄, RFC2822에서 정의된 e-mail 양식에서 개념을 얻어 만들어진 '사람이 쉽게 읽을 수 있는' 데이터 직렬화 양식.

• YAML은 모든 데이터를 리스트, 해쉬, 스칼라 데이터 조합으로 적절히 표현할 수 있다는 믿음을 가지고 만들어졌다. 문법은 상대적으로 이해하기 쉽고, 가독성이 좋도록 디자인되었으며, 고급 컴퓨터 언어에 적합하다. 또한 들여쓰기 및 XML의 특수기호를 사용하기 때문에, XML과 거의 비슷 하다.

• JSON은 yaml의 일종이다.

사용방법 및 Properties와 비교시 이점

• 장점

  1. 가독성이 좋다.
     • 계층 구조로 표현하여 가독성이 좋다. 또한 불필요한 소스의 중복도 제거 할 수 있다.
     • 들여쓰기, 띄어쓰기로 구분하여 보기 편하다.
  2. 리스트 표현
     • 여러 줄에 쓸 때에는 하이픈(-)으로 시작하는 한 줄에 하나의 요소를 표현한다.
     • 한 줄에 모아 쓸 대에는 대괄호([])를 이용하여 쉼표로 각 요소를 구분한다.
  3. 주석
     • 주석은 #으로 표시하며, 한 줄이 끝날 때까지 유효하다.
  4. SpringBoot Profile 적용이 용이하다. (with "---" 구분자)
     • 한파일 내에서 여러 파일을 사용하는 것처럼 분리가 가능하다.
     • application.yml 파일 하나로 여러개의 yml을 생성 한것과 같이 처리 가능

• 단점

  1. @PropertySource 어노테이션으로 프로퍼티 값을 불러 올 수 없다.

0707 - docker 종료

실행중인 도커 컨테이너 정보 확인

docker ps

실행중인 도커 컨테이너 중 spring-boot-cpu-bound 애플리케이션이 포함된 줄 찾기

docker ps | grep spring-boot-cpu-bound

도커 컨테이너 종료시키기

docker container kill -s 15 {컨테이너 id}

0722 - jar, war 차이점 및 특징

JAR(Java Archive) WAR(Web Application Archive) 모두 JAVAdml jar 툴을 이용하여 생성된 압축(아카이브) 파일이며 어플리케이션을 쉽게 배포하고 동작시킬 수 있도록 관련 파일(리소스, 속성파일 등)들을 패키징

JAR

.jar 확장자 파일에는 Class와 같은 Java 리소스와 속성 파일, 라이브러리 및 액세서리 파일이 포함되어 있다.
쉽게 JAVA 어플리케이션이 동작할 수 있도록 자바 프로젝트를 압축한 파일. 실제로 JAR 파일은 플랫폼에 귀속되는 점만 제외하면 WIN ZIP파일과 동일한 구조.
JAR 파일은 원하는 구조로 구성이 가능하며 JDK(Java Development Kit)에 포함하고 있는 JRE(Java Runtime Environment)만 가지고도 실행이 가능.

WAR

.war 확장자 파일은 servlet/jsp 컨테이너에 배치 할 수 있는 웹 어플리케이션(Web Application) 압축 파일 포맷. JSP, SERVLET, JAR, CLASS, XML, HTML, JAVASCRIPT 등 Servlet Context 관련 파일들로 패키징 되어있다. WAR는 웹 응용 프로그램을 위한 포맷이기 때문에 웹 관련 자원만 포함하고 있으며 이를 사용하면 웹 어플리케이션을 쉽게 배포하고 테스트 할 수 있다.
원하는 구성을 할 수 있는 JAR 포맷과 달리 WAR은 WEB-INF 및 META-INF 디렉토리로 사전 정의 된 구조를 사용하며 WAR파일을 실행하려면 Tomcat, Weblogic, Websphere 등의 웹 서버 (WEB)또는 웹 컨테이너(WAS)가 필요하다. WAR 파일도 JAVA의 JAR 옵션(java -jar)을 이용해 생성하는 JAR파일의 일종으로 웹어플리케이션 전체를 패키징하기 위한 JAR파일.

0808 - Maven의 groupId, artifactId, version

groupId

• groupId는 모든 프로젝트 사이에서 고유하게 식별되는 ID

• 다음과 같은 네이밍 스키마 적용

  • package 명명 규칙을 따르도록 한다.
  • 최소한 당신이 컨트롤 하는 도메인 네임이어야 한다.
  • 하위 그룹은 얼마든지 추가할 수 있다.
  • 예) org.apache.maven, org.apache.commons

• 프로젝트 구조를 사용하면 잘 구분되는 groupId를 만들 수 있다.

  • 현재 프로젝ㅌ으가 다중 모듈 프로젝트라면, 부모 groupId에 현재 프로젝트의 식별자를 추가하는 방식.
  • 예) org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

artifactId

• artifactId는 버전 정보를 생략한 jar 파일의 이름이다.
  • 이른은 원하는 것으로 아무거나 정해도 괜찮다.
  • 단, 소문자로만 작성하도록 한다.
  • 단, 특수문자는 사용하지 않는다.
• 만약 써드 파티 jar 파일이라면, 할당된 이름을 사용해야 한다.
  • 예) maven, commons-math

version

• 숫자와 점으로 이루어진 일반적인 버전 형태를 사용한다.(1.0. 1.1, 1.0.1)
• SNAPSHOT(nightly) 빌드 날짜를 버전으로 사용하지 않도록 한다.
• 써드 파티 아티팩트라면, 버전 넘버를 이어받아 사용하도록 한다.