Category: Programming

React 에서 useState 이란?

React 에서 useState 은 훅(Hook) 에 하나다. 함수 컴포넌트에 상태를 추가하기 위한 훅이다.

useState

키 포인트

  1. 초기값(Initialization): useState(initialValue) 은 상태의 초기값을 가진다.
  2. 상태 변수(State Variable): 배열의 첫번째 요소는 현재 상태 값이다.
  3. 업데이터 함수(Updater Function): 배열의 두번째 요소는 상태를 업데이트 하기 위한 함수다.

또 다른 키 포인트는 useState 가 배열로 값을 리턴한다.

여러 예제

여러 상태 값

복잡한 상태 업데이트

배열을 상태로 가지는 예제

팁(Tip)

  • 상태를 변경하기 위해서 업데이트 함수(setState) 를 사용해라.
  • 복잡한 업데이트의 경우, 상태의 오래된 값을 방지하기 위해 setState의 함수형 형태를 사용해라.
  • 상태 객체나 배열을 직접 변경하지 말고 항상 새로운 복사본을 생성하라.

Spring boot 에 systemd 유닛 만들기

요즘 프로젝트를 하고 있는데, 역시나 자바 시스템이 있다. Spring Boot3 을 사용하고 있고 자바 17을 쓰는등 나름대로 괜찮은 환경에서 개발이 이루어지고 있다. 그런데, 이것을 서버에서 배포를 하고 Spring Boot 를 실행해야 하는데, 어떻게 하나 봤더니 초보자 수준도 못 벗어나는 설정을 하고 있으니… 안타까운 마음에 어떻게 하는 것이 좋은 것인지 한번 적어봤다.

Spring boot, jar 실행 파일

Spring Boot3 를 컴파일 하면 jar 파일 나온다. 그리고 별다른 서버 없이도 바로 실행하고 접속이 가능해 진다. 한가지 재미있는 사실은 많은 사람들이 Spring boot3 에 실행 파일 jar 이 내장된 WAS 서버가 구동되면서 실행된다는 걸 모른다는 거다. 심지여 그것이 Tomcat 이라는 것도. 물론 어떤 프로그래밍 모델인지에 따라서 Tomcat 이 되기도 하고 Netty 되기도 하지만, 과연 Reactive Programming Model 로 짜는 사람이 몇이나 있나 싶다. 대부분 Spring MVC 이고 Servlet 이면 기본적으로 Tomcat 이 구동된다. 내장형 Tomcat

프로젝트에서 쓰는 방법

현재 프로젝트에서는 jar 실행을 위해서 스크립트 파일을 만들었다. 대략 다음과 같다.

자바 옵션인 -D 옵션과 jar 실행 파일을 인자로 주고 있다. 그런데, 특이하게도 데몬화를 하지 않았고 많은 초보자식 설정인 nohup 도 없다. 이렇게되면 프로그램이 포그라운드(Foreground) 실행이되어서 쉘이 묶이게 된다.

어떻게 했지? 봤더니 systemd 에 이 실행파일을 넣고 systemd 를 통해서 시작/중지를 하고 있었다. 다음과 같다.

‘ExecStart=’ 에 쉘 스크립트 실행 파일을 지정해 주고 있다.

왜 이렇게 해야 하나? 왜? 이해 할 수 없는 구조다.

Spring 공식 문서

Systemd 유닛에 등록하는 방법은 Spring 공식문서에도 나와 있다.

57.1.2 Installation as a systemd service

이 문서에 나온 systemd 유닛 파일은 프로젝트 유닛 파일과 다르다. 공식 문서에 내용은 그냥 아주 기초적인 내용만 적혀 있다. 실제 프로젝트에 적용하기에는 무리가 있다.

설정파일 작성

Spring boot 를 위한 설정을 systemd 유닛에서 사용할 수 있는 별도의 파일로 작성한다. 이 설정은 JAVA_OPTS 의 내용을 담으면 된다.

이것을 이제 systemd 에서 사용하면 다음과 같다.

공식문서에 나와 있는 내용과 EnvironmentFile 속성으로 외부에서 JAVA_OPTS 를 지정한 내용을 읽어오도록 하면 충분히 사용가능해 진다.

프로젝트에서 처럼 스크립트로 한번 감싸고 이것을 다시 systemd 유닛에서 실행되도록 할 필요가 없다는 것이다.

몇가지 개선 설정

공식문서는 간단한 예이다. 실행이 가능한 정도의 유닛 파일일 뿐이다. systemd 를 이용해 자바 애플리케이션을 실행할 때에는 여러가지를 고려해야 한다.

일단 자바 애플리케이션은 네트워크를 기반으로 한다. 따라서 네트워크 온라인 상태여야 한다. 또, StdOut, StdErr 를 Journal 로 내보내도록 해야 한다.

REST 역사

현대의 소프트웨어 아키텍쳐로 인기가 있는, 아니 어쩌면 전부일 수도 있는 REST 에 대한 역사는 2000년으로 거슬러 올라간다. 시기적으로 그 당시에 한국에서는 IT 버블이라는 현상도 있었던 만큼 IT 관련 기업들이 많이 생겨나고 했던 때다.

2000년 당시를 회상해보면 웹 메일(Web Mail) 서비스를 기반으로 하는 포털들이 많이 있었다. 해외에서는 야후(Yahoo) 가 대표적이였고 마이크로소프트(Microsoft) 의 경우에도 Hotmail 과 함께 MSN 포털을 운영했었다. 국내에서는 다음(Daum) 이 한메일(Hanmail) 서비스를, 네이버(Naver)가 네이버 메일을 기반으로 포털로서 성장하던 때다. 아,,, 네이트도 있었는데, 당시 네이트는 네이트온(NateOn) 메신저가 인기가 있었던 것으로 기억한다.

그 당시에 해외에서도 그렇지만, 소프트웨어 아키텍쳐, 좀 더 정확하게는 이기종간에 데이터 전송을 위한 아키텍쳐로 SOAP(Simple Object Access Protocol) 를 기반으로 구축되었다. 물론 XMLRpc 도 존재했지만 엔터프라이즈 서비스에서는 SOAP 이 거의 표준처럼 사용되던 때였다.

캘리포니아 대학에 Roy Tomas Fielding 이라는 사람이 “Architectural Styles and the Design of Network-based Software Architectures” 논문을 쓴다. 여기에서 서버간의 데이터 전송에 대한 현재까지의 기술을 고찰하고 REST 에 대해서 처음으로 기술하게 된다. 이때가 2000년이였다.

REST 는 HTTP 를 기반으로 하기 때문에 서버의 기종과는 아무런 상관없이 데이터 전송이 가능했다. 더 군다나 그 구조자체가 SOAP 비해서는 매우 단순했기 때문에 데이터 전송에 대한 오버헤더도 줄었다.

이후에 REST 를 기반으로 구축한 업체들이 나타나게 되는데, eBay 가 그중 하나였다. eBay 는 그들의 파트너들에게 필요한 정부를 REST API 형태로 제공했던 것이다. 그때가 2000년 11월즘이였다고 한다. 이후에 Amazon, Flicker 등이 REST 기반 서비스를 제공하게 된다.

Collection Sort Lamba in Java

Java 8 이전에서 객체나 Map 같은 것을 정렬하기 위해서는 Collections 을 사용해야만 했다. 예를들어 다음과 같은 소스다.

하지만 Java 8 에 도임된 람다(Lambda) 를 사용할 경우에 이를 간단하게 해결할 수 있다.

더 나가 람다는 타입을 정의하지 않아도 된다. 컴파일러가 타입을 추론(Inferring) 하게 된다. 따라서 다음과 같이 간단하게 쓸 수 있다.

G1 Collector 기본 설정

G1 GC 의 기본적인 목표는 짧은 STW 시간을 가지고 가는 것이다. 어짜피 STW 를 피하지 못할 바에야 이 시간을 짧게 가지고 가는게 유리하다.

여기서 구분해야할는게 있는데 STW 는 Young GC 일때도 발생한다. 하지만 그 시간이 매우 짧아서 못 느낄 정도일 뿐이다. Old GC 의 경우에는 Young GC 대비 STW 시간이 매우 길다. 그 이유는 Heap 메모리 전체를 청소해야하기 때문이며 청소해야할 공간이 클 수록 Garbage Collector 작동을 위한 자원 소모가 많아진다.

다음과 같은 목표를 갖는다.

  • 짧은 STW 시간을 갖도록 한다.
  • Full GC 가 발생되지 않도록 한다.

여기서 주목해야하는 것이 Full GC 발생하지 않도록 이다.

Full GC 발생 않도록…

MaxTenuringThreshold

이 말은 결국에는 Young GC 만 만들어야 한다는 것을 의미한다. 문제는 live Object 는 결국 최종적으로는 Old Generation 영역으로 이동할 수밖에 없다는데 있다. 그래서 G1 에서는 최대한 Old Generation 영역으로 이동하는 것을 늦출려고 한다. 이에 대한 파라메터가 -XX:MaxTenuringThreshold 다.

  • -XX:MaxTenuringThreshold: Sets the maximum amount of iterations to keep live objects in the new generation. This defaults to 15.

live 객체를 new generation 에 머물게하기 위한 최대 반복횟수로 번역된다. new generation 에서 Young GC 가 발생하면 오래 살아남을 live 객체를 선별되게 된다. 오래 살아남을 live 객체는 당연히 Old generation 영역으로 이동해야 하는데, 이것을 한번에 판단하지 않겠다는 뜻이다.

적어도 여러번.. 기본값으로 15번 정도는 같은 live 객체가 new generation 에서 생존해 있어야 한다. 그래야 ‘아~ 이놈은 오래 살아남을 놈이구나.. Old Generation 으로 옮기자’ 가 된다.

이러한 메커니즘은 Full GC 를 피하기 위한 것이다. Old Generation 에 live 객체가 많아지면 많아질 수록 Full GC 발생가능성은 커진다. 그래서 왠만하면 Young Generation 에 객체를 머물게하고 Garbage 가 되길 기다린다.

MaxGCPauseMillis – Do not set the new generation size unless required.

이 값을 꼭 지정하도록 하고 있다. G1 은 a pause time-target 을 갖는다. 이값은 MaxGCPauseMillis 로 지정하게 되는데 문제는 이 값을 어떻게든 충족되도록 동작하기 뒤해서 G1은 Young Generation 크기를 자동으로 조정하게 된다.

따라서 반드시 Young Generation 크기를 지정해서는 안된다. 오로지 MaxGCPauseMillis 값을 지정해주고 이를 통해서 자동으로 조정되도록 해야 한다. 200 ~ 500 사이에 값을 지정하면 되는데 될수있으면 그냥 기본값으로 둔다.

G1 에서 추천하는 JVM Options

다음은 G1 에서 추천하는 JVM Options 이다.

JVM OptionDetails
-XX:+DisableExplicitGC기본 추천 옵션으로 명시적 GC 를 사용하지 못하게 한다.
-XX:+UseStringDeduplication기본값이 disabled 인데, 켜준다. String deduplication 에 대한 메모리 사용을 줄여준다.
-XX:MaxMetaspaceSize최대 사용가능한 클래스 메타데이터 크기. 네이티브 메모리를 사용한다. 256MB 를 권장하지만 값은 유동적이다.
-XX:MaxTenuringThreshold기본값: 15. new generation 에 live 객체를 유지하기 위한 최대 반복 횟수. 오랫동안 살아남아야할 live 객체가 많다면 값을 낮추고 그렇지않다면 기본값 사용 권장.
-XX:+ParallelRefProcEnabled기본값으로 Disabled 인데, 사용하길 권장.

대략 다음과같이 Command Line 을 사용할 수 있다.

참고: Best practice for JVM Tuning with G1 GC

Spring Boot, error: constructor … in class .. cannot be applied to given types 오류

Spring Boot 로 프로그램을 작성하고 난 후에 Compile 단계에서 다음과 같은 오류를 만날 수 있다.

에러 코드를 보면 new 연산자를 이용해 Employee 객체를 생성하는 부분인데, 이부분이 문제가 된다는 것이다. required: no arguments 라고 나오지만 Employee 는 다음과 같이 되어 있다.

@AllArgsConstructor 어노테이션을 줘서 자동으로 모든 객첵 멤버변수를 인자로 받는 컨스트럭터를 생성하도록 하고 했다. 이것은 Lombok 을 이용한 것으로 다음과 같이 gradle 에서 의존성을 줬다.

문제는 Eclipse 나 IDE 툴에서는 SpringBoot 애플리케이션이 잘만 실행되지만 정작 컴파일을 할려고 하면 위와같은 오류가 나오는다는 것이다. 아무리 봐도 소스코드상에서는 아무런 문제가 없는데도 이런다면 다음과 같이 gradle 에서 annotationProcessor 를 추가해주면 된다.

Maven 을 사용할 경우에는 아무런 문제가 없었지만, Gradle 을 사용하면서 Lombok 을 사용한다면 반드시 annotationProcessor 를 추가해줘야 한다.

IntelliJ 에서는 설정에서 “Enabling Annotation Processing” 체크하면 된다.

JEE 7, JEE 8 and Jakarta EE 8

Java EE 7 Specification

Java EE 7 Overview
Java EE 7 Specification

Java EE 8 Specification

Java EE 8 Overview
Java EE 8 Specification

Jakarta EE 8 Specification

The Jakarta EE 8 has the same set of specifications from Java EE 8 with no changes in its features. The only change is the new process to evolve these specifications. With this, Jakarta EE 8 is a milestone in Java enterprise history, as it inserts these specifications in a new process to boost the specifications to a cloud-native application approach.

Jakarta EE 8: The new era of Java EE explained

Java EE version history

Java EE version history
https://www.packtpub.com/product/building-restful-web-services-with-java-ee-8/9781789532883

Spring5 Security 기초 템플릿 – Session

이 글은 Spring5 에 Spring-Security 에 대한 기초 템플릿이다. Session 유지를 위해서 Redis 를 필요로 한다. 또, ElasticSearch 의 RestHighLevelClient 로 ElasticSearch를 연결 한다. 데이터베이스는 JNDI 설정으로 연결 된다.

다음과 같은 내용을 담았다.

  1. JDK 11
  2. Tomcat 서버 9 를 이용.
  3. spring-session.xml 을 작성해 Redis 를 세션으로 사용하도록 했다.
  4. JNDI 를 이용해 MySQL 에 연결된다.

Redis 설정한 이유는 Spring Security 에 인증을 InMemory 를 요구 한다. 이는 다음과 같은 설정 때문이다.

인증을 위한 패스워드가 {bcrypt} 로 되어 있다. 이 설정은 InMemory 세션을 요구한다. 이를 위해서 spring-session.xml 을 작성해 web.xml 에서 다음과 같이 인식을 시켜 준다.

Spring5 Security 기초 템플릿

이 문서는 Spring5 Security 기초 템플릿에 대한 것이다. Spring5 에 Spring-Security 를 이용해 기초적인 로그인을 구현 했다. Session 은 InMemory 가 아닌 WAS 서버에 세션을 저장한다. 로그인 정보는 spring-security.xml 에 정의된 것을 그대로 사용했다. 그야말로 기초적인 내용만 담았다.

이 템플릿이 동작하기 위한 조건은 다음과 같다.

  1. Java 1.8 기반.
  2. 데이터베이스가 연결되어 있어야 한다. 데이터베이스는 MySQL 이다.
  3. WAS 서버에 JNDI 를 연결된다.
  4. users 테이블이 필요한데, user.sql 파일에 내용이 있다.
  5. spring security 의 Role 기반 권한 접근 제어.
  6. context root 는 malluser 이다.

작동방식

Login 화면

권한을 체크하기 때문에 로그인 화면이 먼저 나온다. 권한 체크는 다음과 같이 Controller 에서 이루어진다.

ROLE_USER 권한을 가지고 있다면 초기화면에 접근이 가능하며 그렇지 않다면 로그인 화면으로 돌아가게 된다.

인증을 위한 정보는 다음과 같이 구현 됐다.

{noop} 은 암화화 되지 않는 text 기반의 암호을 말하는 것이며 위 설정은 외부 정보 저장소를 이용하지 않는 것이다.

로그인을 하면 다음과 같은 화면이 나온다.

로그인 화면

LOGOUT 버튼은 다음과 JSP 에서 Security tags 를 이용해 구현 했다.

Eclipse 에서 제작되었다.

Mybatis에 DAO 와 Mapper

SpringFramework 을 이용하다보면 데이터베이스 액세스를 위해서 MyBatis 를 사용하곤 한다. SQL 매퍼라고 불리기도 하는 것인데, 이를 이용하면 손쉽게 자바 코드와 SQL 문을 분리해줄 수 있을뿐만 아니라 MyBatis 에서 제공하는 여러가지 추가적인 기능을 이용해 데이터베이스를 좀 더 유연하게 사용할 수 있다.

DAO

보통 MyBatis 를 이용할대는 DAO 를 구조를 사용하곤 했다. Data Access Object 라고 불리는 것으로 말 그대로 데이터 접근을 위한 객체로서 sqlSession 객체를 이용해 데이터베이스 조회만 전담하는 객체다.

이 구조는 인터페이스와 그것을 구현한 구현체 클래스가 있어야 한다. 이를 위해서 Spring의 컨텍스트 설정을 해줘야 하는데 대략 다음과 같다.

sqlSession 을 빈으로 등록해준다. 그리고 다음과 같이 DAO 를 작성해 준다.

UserDAOImpl 은 UserDAO 인터페이스의 구현체다. SqlSession 의 빈을 가지고 오기 위해서 와이어를 걸어서 가지고 왔고, SQL 매퍼를 찾기위한 네임스페이스와 파라메터 인자를 주고 selectOne 메소드를 호출하고 있다.

이제 이것을 Service 계층에서, 역시나, 와이어를 걸어서 가지와서 데이터베이스에 데이터를 값을 호출하고 있다.

많은 프로젝트에서 이와 유사한 구조를 자주 보게 된다.

Mapper

그런데, 신기하게도 Mapper 을 이용해서 DAO 를 사용할 수도 있다. 이 기능은 MyBatis 3.0 이상부터 지원하기 시작한 것으로 Mapper 인터페이스만 구현하고 Service 계층에서 바로 와이어를 걸어서 사용할 수 있도록 했다.

하지만 DAO 구조에서도 얼마든지 Mapper 를 사용할 수 있다. sqlSession 에 메소드의 파라메터를 Mapper 클래스로 넘기면 된다. 먼저 Mapper 인터페이스를 다음과 같이 만든다.

그리고 앞에 DAO 구현체에 메소드를 다음과 같이 바꾼다.

sqlSession 객체에는 getMapper 는 메소드가 존재하고 이는 MyBatis 가 지원하는 Mapper 인터페이스를 받게 되어 있다.

문제는 MyBatis 의 namespace 인데, Mapper 인터페이스의 경로를 적어주면 되며 id 가 Mapper 인터페이스의 메소드 이름과 매핑된다.

이렇게 함으로써 Mapper 를 이용하면서도 DAO 구조를 그대로 유지할 수 있다. 문제는 DAO 에서 Mapper 인터페이스 객체를 매번 생성해 줘야 한다는 것이다. sqlSession.getMapper 를 이용해서 매번 가지고 오게 되는데, 이렇게 하는 것보다는 Spring Context 에서 빈으로 등록해 와이어로 가지고 오게 되면 DAO 가 아닌 Service 계층에서 호출이 가능하다.

다음과 같이 빈으로 등록한다.

이제 Service 계층에서 다음과 같이 와이어로 가지고 오고 바로 사용할 수 있다.

하지만 이렇게 할 경우에 Mapper 인터페이스 객체 하나하나 전부 Spring Context 에서 빈으로 만들어 줘야 한다. 그래서 이렇게 하지말고 Mapper 인터페이스를 스캔하도록 할 수 있는데 이를 위해서 mybatis-spring 라이브러리 패키지와 xsd 설정을 해줘야 한다. xsd 과 설정은 Spring Context 파일에 다음과 같이 해준다.

Mapper 인터페이스 클래스 파일들을 전부 위 설정에 나온 패키지 경로로 모두 옮긴다. 그리고 각 Mapper 인터페이스에 @Mapper 어노테이션을 붙여준다. 또한 매퍼 XML 에 네임스페이스 경로도 모두 위 설정으로 바꿔 준다.

이렇게 하면 DAO 관련 파일들은 전부 삭제해도 잘 동작 한다.