빌드를 하다보면 Gradle 로 빌드를 하게되어 개발 테스트시 속도가 저하될수있다.

File | Settings | Build, Execution, Deployment | Build Tools | Gradle 들어가서
Build and run using 을 IntelliJ 로 변경시 IntelliJ 로 빌드를 진행 할수있다.

상수를 사용할때 private static final, private final 차이

private static final Integer THREAD_COUNT = 10;

private final Integer THREAD_COUNT = 10;

- private static final을 선언한 변수를 사용하면 재할당하지 못하며, 메모리에 한 번 올라가면 같은 값을 클래스 내부의 전체 필드, 메서드에서 공유한다.

- private final을 선언한 변수를 사용하면 재할당하지 못하며, 해당 필드, 메서드별로 호출할 때마다 새로이 값이 할당(인스턴스화)한다.

그렇다면 상수로 사용하려고 할 때, 그 값은 변하지않는 값을 호출할 때마다 새롭게 인스턴스화 하여 올릴필요가 없다.
private static final 로 상수가 선언된 부분을 메모리에서 가져다 쓰면된다.

1. 라인번호

File | Settings | Editor | General | Appearance 
- Show line numbers 체크

2. 공백 표기
File | Settings | Editor | General | Appearance 
- Show whitespaces 체크

Spring Cloud Netflix

(https://cloud.spring.io/spring-cloud-netflix/reference/html/)

자동 환경 설정과 Spring Environment 및 다른 Spring 프로그래밍 모델 관념의 바인딩을 바탕으로 Spring Boot 어플리케이션을 위한 Netflix OSS(Open Source Software) 통합을 제공합니다. 몇 가지 간단한 어노테이션을 사용하여 어플리케이션 내부의 공통 패턴을 신속하게 사용하고 설정할 수 있습니다. 그리고 battle-tested를 거친 Netflix component를 통해 대규모 분산 시스템을 구축할 수 있습니다.

제공되는 패턴

• Eureka - Service Discovery & Registry

• Hystrix - Fault Tolerance Library(Circuit Breaker) 

• Zuul- API Gateway  

• Ribbon - Client Side Loadbalancer

기능

• Service Discovery : Eureka 인스턴스를 등록할 수 있으며, client는 Spring이 관리하는 빈을 사용하여 탐지할 수 있습니다.
• Service Discovery : 내장된 Eureka Server는 선언적 java config를 통하여 생성될 수 있습니다.
• Circuit Breaker : Hystrix clients는 간단한 어노테이션 기반으로 구축될 수 있습니다.
• Circuit Breaker : 선언적 java config로 내장된 Hystrix dashboard
• 선언적 REST Client : Feign은 JAX-RS 또는 Spring MVC 어노테이션으로 인터페이스를 동적으로 구현합니다.
• Client Side Load Balancer: Ribbon
• External Configuration : Spring 환경에서 Archaius로 연결 (Spring Boot를 사용하여 Netflix 구성 요소를 설정 가능)
• Router and Filter : Zuul 필터의 자동 등록 및 Reverse Proxy 생성 설정 접근에 대한 간단한 규칙

Zuul (https://github.com/Netflix/zuul)

API를 통해 특정 시스템의 보호된 자원에 접근하기 위해서는 해당 시스템의 사용자 인증 정보(아이디, 패스워드)를 알고 있어야 합니다. 시스템 차원에서 다른 시스템의 보호된 자원에 접근하기 위해 그 시스템의 사용자 인증 정보를 관리하고 이 정보를 사용하는 것은 보안상 많은 문제들을 유발할 수 있습니다. 이런 문제들이 발생하지 않도록 API 접근을 위임하여 인증을 처리하는 방법을 사용할 수 있습니다.

많은 서비스 제공자(Google, Yahoo, AOL 등)들이 이런 인증 방식을 별도로 구현하여 사용하였습니다. 이렇게 구현된 결과들은 서로 조금씩 다르고 서로 호환되지 않았는데 이를 통일하기 위해 OAuth 1.0 표준안을 만들었습니다.

OAuth 1.0 발표 이후 몇 년 동안 사용하면서 커뮤니티는 아래와 같은 단점들에 대해 고민하였고 그 결과 OAuth 2(이후 ‘OAuth’로 명명)를 표준으로 정리하였습니다.

• 암호화 요구사항의 복잡성
• 웹 기반 애플리케이션만 지원
• 성능 확장에 어려움

1. OAuth 역할들(Roles)

OAuth에서 위임 방식의 인가를 처리하기 위해 4 개의 역할들을 정의하고 있으며 이들은 아래 표와 같습니다.

역할설명

2. 인가 승인 유형(Authorization Grant Types)

클라이언트가 접근 토큰을 요청하기 위해서는 자원 소유자의 인가를 받아야 하는데 OAuth는 서로 다른 용도를 위해 다양한 인가 승인 유형을 제공합니다. OAuth에서 정의한 4가지 인가 승인 유형은 아래와 같습니다.

인가 승인 유형용도비고

2.1. 인가 코드 승인(Authorization Code Grant)

인가 코드 승인 방식은 HTTP 리다이렉션 기반 흐름이어서 클라이언트는 자원 소유자의 웹 브라우저와 상호작용할 수 있어야 하며 인가 서버로부터의 요청을 처리할 수 있어야 합니다. 승인 흐름은 아래 그림과 같습니다.

1. 클라이언트가 사용자 에이전트를 인가 서버로 리다이렉트 함으로써 흐름을 시작합니다. (상태(State) 값과 인가 서버로부터 응답을 수신할 Redirect URI 포함)
2. 유효한 인증 이력이 없는 인증 요청에 대해 인가 서버는 로그인 페이지로 응답합니다.
3. 자원 소유자는 인가 서버의 인증을 통해 클라이언트를 인가합니다.
4. 인가 서버는 정상적인 자원 소유자의 인증/인가 요청을 클라이언트로 리다이렉트 합니다. (인가 코드, 상태 값 포함)
5. 인가 코드를 포함한 요청을 받은 클라이언트는 인가 서버로 접근 토큰 요청을 전송하여 그 결과로 접근 토큰을 획득합니다. (인가 코드, 클라이언트 인증 정보 포함)

이 방식은 위 그림에서 볼 수 있듯이 클라이언트의 인증 과정을 거치고 인가 서버와 클라이언트 간에만 접근 토큰이 포함된 통신을 수행하는 등 보안 상 많은 이점을 포함하고 있습니다.

3. 로그인 시나리오

1. SSO 구성 환경에서 SSO 처리 시나리오는 아래 그림과 같습니다.

   한 시스템을 통해 로그인한 사용자가 다른 시스템의 인증이 요구되는 페이지를 요청하면 해당 시스템은 이 요청을 SSO 서버로 리다이렉트 합니다.
   1. 유효한 인증 이력이 있는 요청에 대해 SSO 서버는 이 요청을 시스템으로 리다이렉트 (인가 코드 포함)합니다.
   2. 인가 코드를 포함한 요청을 받은 시스템은 SSO 서버로부터 접근 토큰과 사용자 정보를 획득하여 해당 사용자의 로그인 처리를 한 후 원래 요청의 결과로 응답합니다.

4. 로그아웃 시나리오

로그인한 사용자가 SSO 환경에서 로그아웃 시 처리 과정은 아래 그림과 같습니다.

1. 로그인한 사용자가 한 시스템에게 로그아웃을 요청하면 시스템은 이 요청을 SSO 서버의 로그아웃 페이지로 리다이렉트 합니다.
2. 로그아웃 요청을 받은 SSO 서버는 해당 사용자로 로그인된 모든 시스템에게 로그아웃을 요청합니다.

샘플 소스 코드

https://github.com/Sangjun1/spring-boot-oauth2-example

정규식 표현(Regular Expression)이란?

문법

표현식설명

어디에 사용될까요?

• 텍스트 처리 작업에 매우 유용합니다.
• 데이터 검증(주민번호, 휴대폰 번호등등)에 사용되기도 합니다.

UserName

• 소문자. 숫자. _-포함
• 3글자 이상 16글자 이하

/^[a-z0-9_-]{3,16}$/

Password

• 소문자. 숫자. _-포함
• 6글자 이상 18글자 이하

/^[a-z0-9_-]{6,18}$/

Email

• 소문자. 숫자. _-포함
• @
• 소문자와 . 2글자 이상 6글자이하

/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/

[스프링부트] jar, war 내에서 ResourceUtil.getFile() 사용시 FileNotFoundException 발생

//XML 파일의 내용을 가져온다.
XmlMapper xmlMapper = new XmlMapper();
File file = ResourceUtils.getFile(replicationXmlFilePath);
if (!file.exists()) {
throw new Exception("replication.xml is Not File..");
}

List<DBInfo> dbInfoList = xmlMapper.readValue(file, xmlMapper.getTypeFactory().constructCollectionType(List.class, DBInfo.class));

[ERROR](org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler:95) Unexpected error occurred in scheduled task.
java.io.FileNotFoundException: class path resource [replication.xml] cannot be resolved to absolute file path because it does not reside in the file system: jar:file:/home/service/App.war!/WEB-INF/classes!/replication.xml
        at org.springframework.util.ResourceUtils.getFile(ResourceUtils.java:215)
        at org.springframework.core.io.AbstractFileResolvingResource.getFile(AbstractFileResolvingResource.java:53)
        at com.MonitoringJob.execute(MonitoringJob.java:69)
        at com.JobConfiguration.monitoringJob(JobConfiguration.java:210)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:65)
        at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

Intellij 에서는 Path의 문제가 없었지만 war 내에서는 문제가 생긴다.

//XML 파일의 내용을 가져온다.
XmlMapper xmlMapper = new XmlMapper();
ClassPathResource classPathResource = new ClassPathResource(replicationXmlFilePath);

List<DBInfo> dbInfoList = xmlMapper.readValue(classPathResource.getInputStream(), xmlMapper.getTypeFactory().constructCollectionType(List.class, DBInfo.class));

아래와같이 변경해 주었다.

Docker - 개념

1. 이미지 및 컨테이너로 구성

2. 설정 된 값을 이미지(설정)로 구성하여 컨테이너(실행 환경)에서 실행 할 수 있다.

3. 기존  Hypervisor 엔진을 사용하지 않으며, Docker Engine 을 통한 Guest OS 없이 실행 가능

4. Guest OS가 없으므로, 가상머신(Virtual Machine)과 비교 시 월등한 실행 속도 보장 가능

5. 하드웨어를 가상화하지 않으므로, 메모리 엑세스, 파일 시스템, 네트워크 실행 성능 향상

Docker - 활용 및 서버 환경 구축 자동화

1. 여러 서버에 동일환 환경 구성 시 Docker를 활용한 좋은 사례가 많다.

2. 장애 상황 발생 시 기존 서버 환경을 Docker 이미지로 간단하게 구현할 수 있다.

3. Docker에 이미지를 한 번 생성해 놓은 후 매우 간편하게 동일한 환경을 쉽게 재현 가능

4. Docker Registry Server를 통해 서버 환경에 대한 버전 관리가 가능하다.

5.  웹 서버 환경 구축과 관련한 수많은 반복적인 설정 작업을 매우 간단하게 작업 가능

Docker - 장점

1.  서버의 관리 효율증가

: 어떠한 서버에 무엇이 있는지 관리툴로 볼 수있음.

2. 컨테이너 관리와 모니터링

: 특정 컨테이너이 이상있는지 모니터링 기능이 강화됨.

3. 컨테이너의 백업및 복원의 기능이 쉬움.

Docker가 도입시 문제점

1. docker 라는 개념과 이해도가 필요. (인프라에 대한 개념)

: 현재 만든 jar만 배포가 아니라 image 를 생성하여 배포하는 방법까지 해야 하므로 최초 러닝커브가 있을 가능성이 있음.

2. 최초 구축시 많은 리소스가 필요함. (어떻게 구현 할껀가..? , 어떠한 형식으로 사용 할 것인가..)

: 현 인프라에서 어떠한 방법으로 사용할 것인지 생각해야됨.

: 수행착오가 많을 것으로 판단.