ngrinder는 현재 java 11 버전까지 지원하기 때문에 최대 11버전으로 맞춰줘야한다.

java -version으로 조회했을 때 11이 아닌 상위버전으로 나오면 아래의 명령어들로 11버전으로 맞춰야한다.

vim ~/.bash_profile 파일 안에

JAVA_HOME=/usr/libexec/java_home -v 11.0.19
PATH=$PATH:$JAVA_HOME/bin
export JAVA_HOME
export PATH

bash_profile은 일시적으로 변경하는 방법이라 영구적으로 변경하려면 ~/.zshrc를 수정해야한다.

export JAVA_HOME=$(/usr/libexec/java_home -v 11.0.19)
export PATH=$PATH:$JAVA_HOME/bin

추가 후 

source ~/.zshrc 적용

최신 버전의 ngrinder를 다운받는다.

https://github.com/naver/ngrinder/releases/download/ngrinder-3.5.9-p1-20240613/ngrinder-controller-3.5.9-p1.war

다운받은 ngrinder를 적당한 파일 경로에 위치시켜주고 /Users/user/ngrinder 파일에 위치시켜줬다.

 java -Djava.io.tmpdir=${NGRINDER_HOME}/.ngrinder/lib -jar ngrinder-controller-3.5.9-p1.war --port 7070 명령어를 실행시켜 ngrinder를 실행시킨다.

ngrinder를 실행시킨 후 script를 작성하려할 때 계속되는

ERROR FileEntryRepository.java:192 : Error while fetching files from SVN for admin 오류로 인해.. 원인은 알 수 없고 곤란했는데 아래 url처럼 삭제했다가 다시 지우니깐 됐다.(근데 이것도 2차례 정도 지우니깐 그제서야.. 제대로 작동함. 안 되면 여러번 삭제했다가 다시 시도해볼 것)

https://github.com/naver/ngrinder/discussions/968

 implementation("com.querydsl:querydsl-jpa:5.0.0:jakarta")
 implementation("com.querydsl:querydsl-apt:5.0.0:jakarta")

build.gradle.kts 파일에 아래 내용을 추가해준다.

plugins {
	kotlin("kapt") version "1.9.23"
}

dependencies {
    // querydsl
    implementation("com.querydsl:querydsl-jpa:5.1.0:jakarta")
    implementation("com.querydsl:querydsl-apt:5.1.0:jakarta")
    kapt("com.querydsl:querydsl-apt:5.1.0:jakarta")
    kapt("org.springframework.boot:spring-boot-configuration-processor")

    implementation("org.hibernate:hibernate-core:6.1.0.Final")

}

kapt 플러그인을 추가해 kotlin에서도 querydsl을 사용할 수 있게 해준다.

gradle clean 후 build를 해주면 build > classes > generated > source > kapt 경로에 Q클래스들이 생성된다. 

springboot3으로 버전이 올라가면서 jdk는 17 버전을 선택하게 됨. 17버전부터는 javax -> jakarta 패키지로 변경되어 의존성 추가 시 뒤에 classifier에 jakarta를 표기해야함.

 implementation("com.querydsl:querydsl-jpa:5.0.0:jakarta")
 implementation("com.querydsl:querydsl-apt:5.0.0:jakarta")

kotlin + queryDSL를 사용해서 개발하던 중 아래와 같은 오류를 마주함.

and token 'SEPARATOR', no viable alternative at input 'select table_a.cstCd, table_a.cstNm, table_a.orderNo, group_concat(table_a.goodsSno *SEPARATOR '|')'
from shopOrder shopOrder

mysql에서 사용하던 group_concat 함수를 아래와 같이 등록하여 사용하던 중에 group_concat의 기본 separator가 콤마라서 |로 바꾸려고 하는 중에 separator는 사용할 수 없는 명령어라는 오류 발생 여러가지 방법으로 시도하려고 했으나.. 해결되지 않아 어쩔 수 없이 자바단에 함수를 생성하여 replace하는 것으로 변경

override fun contributeFunctions(functionContributions: FunctionContributions) {
    functionContributions.functionRegistry.register("GROUP_CONCAT", StandardSQLFunction(
        "group_concat",
        StandardBasicTypes.STRING
    ))
}

mysql의 group_concat을 querydsl에서 사용하려면 함수를 등록해야 사용할 수 있다. 그렇지 않으면 아래와 같은 에러 발생

2024-07-03T14:41:55.736+09:00 ERROR 54176 --- [nio-1899-exec-4] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.dao.InvalidDataAccessApiUsageException: org.hibernate.QueryException: No data type for node: org.hibernate.hql.internal.ast.tree.MethodNode 
 \-[METHOD_CALL] MethodNode: '('
    +-[METHOD_NAME] IdentNode: 'group_concat' {originalText=group_concat}
    \-[EXPR_LIST] SqlNode: 'exprList'
       \-[DOT] DotNode: 'or0_.goods_sno' {propertyName=goodsSno,dereferenceType=PRIMITIVE,getPropertyPath=goodsSno,path=Ord.goodsSno,tableAlias=or0_,className=com.xxxx.orderapi.domain.order.entity.Ord,classAlias=Ord}
          +-[ALIAS_REF] IdentNode: 'or0_.order_no, or0_.goods_sno' {alias=ord, className=com.xxxxx.orderapi.domain.order.entity.ord, tableAlias=or0_}
          \-[IDENT] IdentNode: 'gdmGoodsSno' {originalText=gdmGoodsSno}
 [select ord.cstCd, ord.orderNo, ord.invoiceNo, ord.invoiceCompanySno, group_concat(ord.goodsSno)
from com.xxxxx.rderapi.domain.order.entity.Ord ord]] with root cause

아래처럼 DBDiaclect을 extends한 후 function을 추가하여 group_concat을 사용할 수 있도록 등록함.

class CustomMySQLDialect: MariaDBDialect() {

    override fun contributeFunctions(functionContributions: FunctionContributions) {
        functionContributions.functionRegistry.register("GROUP_CONCAT", StandardSQLFunction(
            "group_concat",
            StandardBasicTypes.STRING
        ))
    }
}

ByteArray.toString()를 하니 당연히 byteArray의 주소값이 출력된다. 

1. toString() 호출 시 charset를 인자로 넘겨준다.

val bytes = "Hi".toByteArray()
val bytesToString = bytes.toString(Charset.defaultCharset())

=> Prints: "Hi" not bytearray ID "[B@9a7d34b"

2. String 생성자의 인자로 넘겨준다.

val bytes = "Hi".toByteArray()
val bytesToString = String(bytes)

=> Prints: "Hi" not bytearray ID "[B@9a7d34b"

@Transactional 어노테이션 사용 시 사용자가 지정한 rollback rules이 없을 경우 RuntimeException, Error일 때 롤백되고 checked Exception에선 롤백되지 않는다.

상황 : 같은 Class 내 오류가 발생해도 서로 다른 propagation을 설정해 부모 트랜잭션에서 오류가 발생해도 자식 트랜잭션은 커밋되게 동작시키려함

예상한 동작 방식 : saveContent내부의 save는 동작하지 않아도 updateContent내부의 save는 동작할 것으로 예상함.

이유 : require_new로 트랜잭션을 신규로 생성했고 부모에서 exception이 발생해도 자식은 트랜잭션이 신규로 생성되기 때문에 save될 것이라 예상함

    @Transactional(rollbackFor = Exception.class)
    public void saveContent(BoardDTO boardDTO) throws Exception {

        Board board = new Board(boardDTO);
        boardRepository.save(board);
        updateContent(1000L, boardDTO);
        throw new RuntimeException();

    }

    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void updateContent(Long contentId, BoardDTO boardDTO) {
        Board board = boardRepository.findById(contentId).orElseThrow();
        board.updateContent(boardDTO.getTitle(), boardDTO.getContent());
        boardRepository.save(board);
    }

위의 예제 코드로 테스트를 하였으나 내가 기대한 방식으로 동작하지 않았고 원인은 Spring에서 @Transactional 어노테이션에 대한 동작 방식 때문이었다. @Transaction 어노테이션은 Spring의 AOP를 통해 프록시 객체를 생성하여 사용된다.

Target 클래스가 인터페이스 구현체가 아니어서 테스트 코드상에서는 CGLib Proxy 방식으로 Target 클래스를 프록시 객체로 생성하여 코드에 끼워넣는 방식이 사용됐다.

문제는 Target 클래스를 프록시 객체로 생성의 특징으로 인해 발생했는데 동일한 Class내에 위치한 메서드에 각기 다른 @Transactional propagation 옵션을 설정했지만 메소드 단위가 아닌 Target클래스 단위로 설정되기 때문에 새로운 트랜잭션이 생성되지 않는다.

이를 해결하기 위해선 메소드를 다른 클래스로 분리(bean을 분리해줌)시키면 외부에서 호출하기 때문에 Target클래스 단위로 트랜잭션이 생성될 수 있고(propagation 전파 옵션에 따라) 부모가 실패해도 자식 트랜잭션은 커밋될 수 있도록 설정할 수 있다. 

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration': Unsatisfied dependency expressed through method 'setFilterChains' parameter 0: Error creating bean with name 'filterChain' defined in class path resource [com/example/securityspring/config/SecurityConfig.class]: Failed to instantiate [org.springframework.security.web.SecurityFilterChain]: Factory method 'filterChain' threw exception with message: This method cannot decide whether these patterns are Spring MVC patterns or not. If this endpoint is a Spring MVC endpoint, please use requestMatchers(MvcRequestMatcher); otherwise, please use requestMatchers(AntPathRequestMatcher).

This is because there is more than one mappable servlet in your servlet context: {org.h2.server.web.JakartaWebServlet=[/h2-console/*], org.springframework.web.servlet.DispatcherServlet=[/]}.

For each MvcRequestMatcher, call MvcRequestMatcher#setServletPath to indicate the servlet path.

위와 같은 오류 발생 문제의 원인은 h2 데이터베이스의 console 사용을 아래와 같이 허용해주었는데 h2 console 사용 시 서블릿 컨텍스트에 h2-console과 dispatcherServlet의 두 가지 서블릿이 매핑되어 어떤 서블릿을 사용해야하는지 알 수 없어 발생하는 오류

application.yml

spring:

  h2:
    console:
      enabled: true

filterChain의 requestMatchers에 MvcRequestMatcher, AntPathRequestMatcher 중 사용하려는 클래스를 명확하게 지정해줘야한다. 

@Bean
public SecurityFilterChain filterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception {
	http.authorizeHttpRequests((authz) -> authz
    		.requestMatchers(new MvcRequestMatcher(introspector,"/api/hello")).permitAll()
		.anyRequest().authenticated())
		.httpBasic(Customizer.withDefaults());
	return http.build();
}

오류만 제대로 읽었어도 금방 찾을 수 있는 에러였다.

• 기본 타입 / 박싱 타입의 차이

기본 타입과 박싱된 기본 타입을 혼용한 연산에서는 박싱된 기본 타입의 박싱이 자동으로 풀린다.

static Integer i;

public static void main(String[] args) {
    if ( i == 42) //null 참조를 언박싱하면서 NullPointerException이 발생한다
        System.out.println("믿을 수 없군!"); 
}

박싱된 기본 타입을 사용하는 경우

• 컬렉션의 원소, 키, 값
• 매개변수화 타입이나 매개변수화 메서드의 타입 매개변수로는 박싱된 기본 타입을 사용
• 리플렉션을 통해 메서드를 호출할 때도 박싱된 기본 타입 사용

컬렉션이나 배열 같은 컨테이너(container)가 비었을 때 null을 반환하는 메서드를 사용하면 방어 코드를 넣어줘야 한다.

private final List<Cheese> cheesesInStock = ....;

public List<Cheese> getCheeses() {
	return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock);
}

제거기 앖디거 특별한 취급을 할 필요는 없지만 아래와 같이 방어 코드가 필요하다.

List<Cheese> cheese = shop.getCheeses();
if (cheese != null && cheeses.contains(Cheese.STILTON)) 
	Sytem.out.println("좋았어, 바로 그거야.");

사용 패턴에 따라 빈 컬렉션 할당이 성능을 떨어뜨리는 경우 매번 똑같은 빈 '불변' 컬렉션을 반환하면 된다.

Collections.emptySet, Collections.emptyMap을 사용하면 된다. 

최적화가 필요하다고 판단되면 수정 전과 후의 성능을 측정하여 실제로 성능이 개선 되는지 꼭 확인하자.

return cheeseInStock.toArray(new Cheese[cheeseInStock.size()]);

null이 아닌, 빈 배열이나 컬렉션을 반환하라. null을 반환하는 API는 사용하기 어렵고 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은 것도 아니다.

메서드 이름을 신중히 짓자.

같은 패키지에 속한 다른 이름들과 일관되게 짓는게 최우선 목표다. 

편의 메서드^※를 너무 많이 만들지 말자.

매개변수 목록은 짧게 유지하자. 4개 이하를 권장

1. 여러 메서드로 쪼갠다.
   • 잘못하면 메서드가 많아질 수 있으나 직교성^※을 높여 메서드를 줄여주는 효과가 있다.
   • subList, indexOf메서드를 사용하여 부분리스트에서 인덱스를 찾는 예시
2.  매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것이다.
   • 도우미 클래스는 정적 멤버 클래스로 둔다.
3. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용
4. 매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다
5. boolean보다는 우너소 2개짜리 열거 타입이 낫다

직교성 

• 공통점이 없는 기능들이 잘 분리되어 있다.
• 기능을 원자적으로 쪼개 제공한다.
• API가 다루는 개념의 추상화 수준에 맞춰 원자적으로 쪼개야한다.
• MSA 아키텍처는 직교성이 높고 모놀리식 아키텍처는 직교성이 낮다.

클라이언트가 여러분의 불변식을 깨드리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다. 

Date 대신 불변(아이템 17)인 Instant, LocalDateTime, ZonedDateTime을 사용하면 된다.

외부 공격으로부터 Period 인스턴스의 내부를 보호하려면 생성자에서 받은 가변 매개변수 각각을 방어적으로 복사(defensive copy)해야 한다. 그런 다음 Period 인스턴스 안에서는 원본이 아닌 복사본을 사용한다.

매개변수가 제3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone을 사용해서는 안 된다.

접근자가 가변 필드의 방어적 본사본을 반환하면 된다.

내부에서 사용하는 배열을 클라이언트에 반환할 때는 항상 방어적 복사를 수행해야 한다. 혹은 배열의 불변 뷰를 반환하는 대안도 있다. 

private static final Thing[] PRIVATE_VALUES = {...};
public static final Thing[] values() {
	return PRIVATE_VALUES.clone();
}

메서드나 생성자의 매개변수로 넘기는 행위가 그 객체의 통제권을 명백히 이전함을 뜻하기도 한다. 불변식이 깨지더라도 그 영향이 오직 호출한 클라이언트로 국한될 때로 한정해야한다. (래퍼 클래스 패턴을 예로 들 수 있다.)

메서드 몸체가 시작되기 전에 매개변수가 유효한지 검사해야한다. (오류는 가능한 한 빨리 발생한 곳에서 잡아야 한다) 실패 원자성을 어기는 결과를 낳을 수 있다.

• 메서드가 수행되는 중간에 모호환 예외를 던지며 실패할 수 있다.
• 미래의 알 수 없는 시점에 이 메서드와 관련 없는 오류를 낼 수 있다. 

생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 개체가 만들어지지 않게 하는데 꼭 필요하다.

메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야한다.