WhiteLabel Error

어떤 페이지로 접속을 했는데 그런데 React로 보여야할 페이지가 나오지 않고 Spring 서버로 Get요청이 들어갔다.. 그래서 Whitelabel Error Page가 나오는데 이때 생각난 것은 저번 프로젝트에서 정적 리소스 접근에 대한 설정을 했던 것이다

해결 방법

WebMvcConfigurer를 구현하는 Config 클래스를 생성하고 addResourceHandlers(registry: ResourceHandlerRegistry) 메서드를 override하여 그 안에 다음 코드를 작성한다 정적 리소스 위치는 각자의 환경에 맞게 설정한다

registry.addResourceHandler("/**")
    .addResourceLocations("classpath:/dist/")
    .resourceChain(true)
    .addResolver(object : PathResourceResolver(){
        override fun getResource(resourcePath: String, location: Resource): Resource? {
                val requestResource = location.createRelative(resourcePath)
                    return if(requestResource.exists() && requestResource.isReadable) requestResource
                    else ClassPathResource("/dist/index.html")
                }
        })

서버는 AWS ec2를 사용하며, 앱은 Docker 컨테이너에서 동작한다

1. Jenkins 설정

• gradle, nodejs, github/gitlab 등 플러그인을 설치하고 설정을 시작한다

  Jenkins 관리 > 시스템 설정

• Jenkins가 실행중인 서버의 URL 작성
• Gitlab / Github URL 작성 Git 접근을 위해 AccessToken을 받아 Credential에 설정한다
• ssh로 서버에 접속하기 위한 설정 Remote Directory 는 ssh 접속 시 들어가는 경로. 꼭 설정할 것 Docker 명령어를 실행할 디렉토리
• 프로젝트 빌드 설정 (Gradle, Maven) 사용할 gradle 버전 설정
• NodeJS 설정

  프로젝트 생성 & 설정

• freestyle project 로 생성
• 소스코드 관리 빌드할 repository의 url, 브랜치 설정 인증을 위한 Credential(계정) 설정 (Username with password)
• 빌드 유발 원하는 빌드 유발 설정을 한다 GitLab webhook 설정에 아래 webhook URL을 사용하니 이 부분을 꼭 기억하자 Webhook 설정을 위한 Secret token을 발급한다
• 빌드 환경 설정
• 빌드 시 필요한 명령어를 작성한다 빌드에 필요하지만 버전 관리 되지 않는 파일은 Filezilla로 업로드하여 명령어를 통해 복사했다
• 빌드 후 조치 ssh 연결을 위한 설정을 해주고 docker 명령어를 실행할 위치로 jar 파일을 옮겨야 하니 그에 대한 설정을 한다 Source files는 말그대로 옮길 파일을 특정한다 Remove prefix는 Source files에 작성한 파일의 경로의 앞에서 지울 부분을 정한다 Remote directory는 파일을 옮길 디렉토리다 (위에서 설정한 Root directory 다음부분을 쓴다) Exec command는 파일을 옮긴 후 실행할 명령어를 작성한다

  2. Gitlab 설정

• Webhook Jenkins 프로젝트 > 구성 > 빌드 유발 에서 발급한 토큰을 사용하고, 빌드 트리거를 설정한다

많은 클래스는 하나 이상의 자원에 의존한다 예) 사전에 의존하는 맞춤법 검사기 클래스

정적 유틸리티 클래스로 구현

정적 유틸리티를 잘못 사용한 예 유연하지 않고 테스트하기 어렵다

public class SpellChecker{
    private static final Lexicon dictionary = ...;

    private SpellChecker(){} // 인스턴스 생성 방지

    public static boolean isValid(String word){ ... }
    ...
}

싱글턴도 가능

싱글턴을 잘못 사용한 예 유연하지 않고 테스트하기 어렵다

public class SpellChecker{
    private static final Lexicon dictionary = ...;

    private SpellChecker(...){}
    public static SpellChecker INSTANCE = new SpellChecker(...);

    public static boolean isValid(String word){ ... }
    ...
}

둘 다 사전을 하나만 사용함 -> 확장할 수 없다 자원에 따라 동작이 달라지는 클래스는 정적 유틸리티 클래스나 싱글턴이 적합하지 않다 사용자가 원하는 자원을 사용할 수 있게 해야하는데..

인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주면 된다!

의존 객체 주입 패턴

public class SpellChecker{
    private static final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary){
        this.dictionary = Objects.requireNonNull(dictionary);
    }

    public static boolean isValid(String word){ ... }
    ...
}

자원이 몇 개든 의존 관계가 어떻든 상관없다 객체가 불변임을 보장하여 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있다 생성자, 정적 팩토리, 빌더에 똑같이 적용 가능

의존 객체 주입 프레임워크 Dagger, Guice, Spring

정리

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다. 자원들을 클래스가 직접 만들게 해서도 안된다. 대신, 필요한 자원 또는 자원을 만들어주는 팩토리를 생성자, 정적 팩토리, 빌더에 넘겨주자. 의존 객체 주입이라 하는 이 기법은 클래스의 유연성, 재사용성, 테스트 용이성을 크게 개선해준다.

1. Entity 생성

@Entity
public class Board {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private long no;
    private String userid;
    private String subject;
    private String content;
    ...
}

2. Repository 생성

PagingAndSortingRepository를 상속한 BoardRepository를 만든다. PagingAndSortingRepository를 상속한 JPARepository를 상속해도 된다.

public interface BoardRepository extends PagingAndSortingRepository<Board, Long>{
    List<Board> findAllByUserId(String userId, Pageable pageable);
}

PagingAndSortingRepository 인터페이스를 보자. findAll(Sort sort), findAll(Pageable pageable) 메서드가 있다.

@NoRepositoryBean
public interface PagingAndSortingRepository<T, ID> extends CrudRepository<T, ID> {
    /**
     * Returns all entities sorted by the given options.
     *
     * @param sort
     * @return all entities sorted by the given options
     */
    Iterable<T> findAll(Sort sort);

    /**
     * Returns a {@link Page} of entities meeting the paging restriction provided in the {@code Pageable} object.
     *
     * @param pageable
     * @return a page of entities
     */
    Page<T> findAll(Pageable pageable);
}

3. 페이징 처리

이제 데이터를 조회해보자 PageRequest 객체를 생성하고 findAll 메서드에 파라미터로 전달한다. 페이지 번호는 0부터 시작하므로 pno에서 1을 뺀 값을 전달한다.

// 10개씩 나누어 페이징하고, 페이지 번호가 pno-1인 데이터들을 가져온다
Pageable pageWithTenElements = PageRequest.of(pno - 1, 10, Direction.DESC, "no");
noticeRepo.findAll(pageable);

4. 페이징 및 정렬

정렬된 결과를 얻으려면 메서드에 Sort 객체를 전달한다.

Page<Board> boardsSortedByUserId = boardRepository.findAll(Sort.by("userId"));

페이징과 정렬 둘 다 하고싶으면 아래 코드처럼 PageRequest 객체를 생성하여 사용한다.

Pageable sortedByUserId = 
  PageRequest.of(0, 3, Sort.by("userId"));

Pageable sortedByUserIdDesc = 
  PageRequest.of(0, 3, Sort.by("userId").descending());

Pageable sortedByUserIdDescNoAsc = 
  PageRequest.of(0, 5, Sort.by("userId").descending().and(Sort.by("no")));

참고한 Baeldung 문서 https://www.baeldung.com/spring-data-jpa-pagination-sorting

생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다.

new Boolean("true");
// 위(생성자) 대신 아래 코드를 사용한다
Boolean.valueOf("true");

생성 비용이 비싼 객체가 있으면 재사용하자

다음과 같은 예시가 있다.

static boolean isRomanNumeral(String s){
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3}"
            + "((X[CL]|L?X{0,3})(I[XV]|v?I{0,3})$";
}

String.matches()의 Pattern 인스턴스는 한 번 쓰고 버려지는데, Pattern은 입력받은 정규표현식에 해당하는 유한 상태 머신을 만들기 때문에 인스턴스 생성 비용이 높고, 그래서 그 객체를 재사용해서 성능을 개선할 수 있다고 한다.

// 성능 개선
public class RomanNumerals{
    private static final Pattern ROMAN = Pattern.compile(
            "^(?=.)M*(C[MD]|D?C{0,3}"
            + "((X[CL]|L?X{0,3})(I[XV]|v?I{0,3})$");
    static boolean isRomanNumeral(String s){
        return ROMAN.matchers(s).matches();
    }
}

오토박싱으로 인해 불필요한 객체가 생성되지 않도록 하자

Long sum = 0L;
for(long i = 0; i <= Integer.MAX_VALUE; i++){
    sum += i;
}

Long 타입의 sum 변수에 i를 더할 때마다 오토박싱으로 인해 불필요한 Long 인스턴스가 생성된다. 그래서 제대로 짠 코드보다 훨씬 느리다. sum 변수를 long 타입으로 바꾸자. 저자는 Long을 사용할 때보다 실행 시간이 10배 빨라졌다고 한다.

불필요한 객체 생성을 피한 예

Map인터페이스의 keySet 메서드가 반환하는 Set객체를 보면 알 수 있다. 이 코드를 실행하면 keySet2에서 1이 사라진 것을 알 수 있다.

Map<Integer, String> map = new HashMap<>();
map.put(1,"one");
map.put(2,"two");
map.put(3,"three");
Set<Integer> keySet1 = map.keySet();
Set<Integer> keySet2 = map.keySet();
keySet1.remove(1);
for (int i : keySet2){
    System.out.println(i);
}

스프링에서 권장하는 일반적인 DI 가이드라인은 다음과 같다.

• 필수 의존성이나 불변성이 목적이면 생성자 주입을 사용한다.
• 선택적 또는 변경 가능한 의존성에는 setter 주입을 사용한다.
• 웬만하면 필드 주입을 피하라.

Field Injection의 단점

• 생성자 주입처럼 변경할 수 없는 객체를 만들 수 없다.
• 클래스는 DI 컨테이너와 긴밀하게 연결되어 있으며 외부에서 사용할 수 없다.
• 리플렉션 없이는 클래스를 인스턴스화할 수 없다. 인스턴스화하려면 DI 컨테이너가 필요하므로 테스트를 통합 테스트와 유사하게 만든다.
• 실제 의존성은 외부에서 숨겨져 있으며 인터페이스(생성자 또는 메서드)에 반영되지 않는다.

결론

필요에 따라 생성자 주입을 사용하거나 생성자와 setter 주입을 혼합하여 사용해야 한다. 필드 주입에는 많은 단점이 있으므로 피해야 한다. 유일한 장점은 쓰기가 더 편리하다는 것이다.

참고