사랑하기 위해 필요한 것들

ModelMapper**의 설정 코드를 해석해 드리겠습니다. 이 코드는 객체 간의 매핑 규칙을 세밀하게 제어하기 위한 설정입니다.

1. setFieldAccessLevel(AccessLevel.PRIVATE)

이 설정은 ModelMapper가 필드에 직접 접근할 때 접근 레벨을 PRIVATE으로 설정하는 역할을 합니다. 일반적으로 ModelMapper는 getter/setter 메소드를 통해 필드에 접근하지만, 이 설정을 활성화하면 private 필드에도 직접 접근하여 값을 매핑할 수 있게 됩니다. 이는 getter/setter가 없는 클래스를 매핑할 때 유용합니다.

2. setFieldMatchingEnabled(true)

이 설정은 필드 매칭을 활성화하는 코드입니다. ModelMapper는 기본적으로 getter/setter를 사용한 메소드 매칭 전략을 따릅니다. 하지만 이 설정을 true로 설정하면 getter/setter 대신 필드 이름을 기반으로 소스 객체의 필드와 대상 객체의 필드를 매칭합니다.

3. setMatchingStrategy(MatchingStrategies.LOOSE)

이 설정은 매칭 전략을 LOOSE로 설정하는 코드입니다. ModelMapper는 세 가지 매칭 전략을 제공합니다.

• STRICT: 모든 소스 필드와 대상 필드의 이름이 정확히 일치해야 합니다.
• STANDARD: 소스 필드와 대상 필드의 이름이 비슷해야 합니다. (예: user.name과 userName)
• LOOSE: 소스 필드와 대상 필드의 이름이 대소문자나 구분자 없이 매칭됩니다. (예: userId와 user_id 또는 user-id) 이 전략은 가장 유연하며, 필드 이름이 정확히 일치하지 않아도 매핑이 가능합니다.

종합 해석

위 코드를 전체적으로 해석하면 다음과 같습니다.

ModelMapper가 getter/setter 없이도 private 필드에 직접 접근하여, 필드 이름만으로도 대소문자나 구분자 등에 상관없이 가장 유연하게 객체를 매핑하도록 설정한다.

package com.mysite.backend.config;

import org.modelmapper.ModelMapper;
import org.modelmapper.convention.MatchingStrategies;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RootConfig {
    @Bean
    public ModelMapper getMapper(){
        ModelMapper modelMapper = new ModelMapper();
        // 1. setFieldAccessLevel : private 필드에서도 직접 접근하여 값을 매핑 할 수 있게 함
        // 2. setFieldMatchingEnabled : getter/setter 대신 필드이름 기반으로 소스 객체 필드와 대상 객체 필드를 매칭함
        // 3. setMatchingStrategy : 소스 필드와 대상 필드간 매칭 설정
        modelMapper.getConfiguration().setFieldAccessLevel(org.modelmapper.config.Configuration.AccessLevel.PRIVATE)
                .setFieldMatchingEnabled(true)
                .setMatchingStrategy(MatchingStrategies.LOOSE);
        return modelMapper;
    }
}

1. 롬복 설치하기

롬복 다운로드로 이동해서 롬복을 다운로드해 주세요.

버전은 2018-03-07일 기준으로 1.18.12 버전입니다.

"jar 파일은 다운로드 중에 컴퓨터를 손상시킬 수도 있다."라는 경고 메시지가 나오는데요,

무시하고 계속을 클릭해서 진행해 주시면 되겠습니다.

@Resource @Autowired @Inject 의 공통점은 의존 주입 이다.

또한 특정 Bean 기능을 수행하기 위해 기능에 필요한 특정 Bean을 참조 해야 하는 경우가 많이 발생한다

그럴때 사용하는것이 @Resource @Autowired @Inject 의 어노테이션이다

그럼 이 어노테이션의 차이점과 사용법을 알아보도록 하자.

간단한 설명은 이렇게 자세한 설명을 이어가겠다.

@Resource

은 name 으로 DI 를 가능케한다. 자바에서 지원하는 어노테이션 이며 프레임워크에 종속적이지 않아 많이 사용한다. 이걸 추천한다.

다 똑같지만 필요로 하는 자원을 쓰기 위해 어노테이션을 추가해 DI를 한다.

Bean을 생성해주며 싱글톤 패턴이 자동으로 적용이 된다고 생각하면 된다.

@Autowired

은 type으로 DI 를 가능케한다. 스프링 프레임워크에서 지원 하는 어노테이션이면 프레임워크에 종속적이다.

그래서 추천하지는 않는다 왜냐하면 스프링 프레임워크를 쓰다 다른 프레임워크로 수정할 경우에 많은 리소스가 발생한다

다 바꿔줘야하는 부분이... 양이 방대하다면 답이 없고

그래서 나는 Resource를 추천한다 어느 프레임워크에 종속적이지 않기 때문에

이것또한 Bean를 생성하며 싱글톤 패턴이 자동으로 적용이 된다. 타입으로 연결 하기 때문에 같은 타입인 여러개의 필드는 오류가 날것이다

강제 연결 할경우에는 @Qualifier를 사용하면 된다 네임을 붙혀서

@Inject

은 name으로 DI를 가능케한다. 자바에서 지원하는 어노테이션 이며 프레임 워크에 종속적이지 않아 사용해도 좋다

이것은 @Resource 랑 다를게 없지만 다른점이라하면 자바에서 지원하는건데 타입으로 연결한다는 점이다

Autowired 를 사용할거라면 차라리 Inject를 사용하는 걸 추천하는 편이기는 한다

다만 오토와이어는 확실한 의존성이 보장이 되기때문에 이거는 어느걸 추천한다고는 확실히 답변 못주겠다.

알아서 리소스와 코드의 맞게 써라

형상관리 프로그램 SVN을 사용하다 보면...

lock 걸려서 update도 안되고 commit 도 안되고...

그래서 cleanup을 해서 풀려고 해도 안되고...

참으로 짜증날 때가 있다.

lock 이 걸리는 부분에 대해서 아직도 정확히 어느시점에 왜?! 걸리는지 모르겠다는...

update 받고 commit 하는데 갑자기 lock 걸려버림...

내가 무슨잘못을 한건지....

찾아보면 다들 cleanup 시키라는데

해봤자 lock 이 걸려서 cleanup 자체가 되지 않음

이래 될때 마다 매번 새로 받을 수도 없는 노릇이고 해서 SVN db를 까봄

.svn 폴더를 들어가보면 wc.db 파일이 존재함.

요녀석을 sqlite3 으로 열어봄

SQLite Browser 다운로드 링크

http://sqlitebrowser.org/

DB Browser for SQLite

News 2016-12-17 - The v3.9.1 binary for OSX has been rebuilt using Qt 5.7.1, to fix an important colour display problem on macOS Sierra. 2016-12-15 - An initial DBHub.io server is online , running our latest development code. Testing and feedback is encouraged . Note - The data on this server will p...

sqlitebrowser.org

wc.db 내부 테이블 중에

WC_LOCK, WORK_QUEUE 테이블이 존재함.

물론 SVN이 이상없을 시에는 이곳에 데이터가 쌓여있지 않음.

LOCK이 걸려서 이러지도 저러지도 못할때 조회해보면 그 해당 에러났던 파일들이 들어있음.

과감하게

DELETE FROM WC_LOCK

DELETE FROM WORK_QUEUE

SQL 실행 후 변경사항을 저장시키고 LOCK 걸린곳에서 cleanup을 한 후

update 실행하면 lock이 해제되어 있는것을 볼 수 있다.

문제 상황

인터넷이 연결되어 있을때는 정상이지만 연결되어 있지 않으면 톰캣 실행시 아래와 같은 에러 발생.

참고로 웹소켓을 연동한 프로젝트였다.

org.xml.sax.SAXParseException; lineNumber: 95; columnNumber: 84; schema_reference.4: 스키마 문서 'http://www.springframework.org/schema/util/spring-util-3.2.xsd' 읽기를 실패했습니다. 원인: 1) 문서를 찾을 수 없습니다. 2) 문서를 읽을 수 없습니다. 3) 문서의 루트 요소가 가 아닙니다.

Caused by: java.net.UnknownHostException: www.springframework.org

2014-09-04 10:34:22,195 [localhost-startStop-1] ERROR [org.springframework.web.servlet.DispatcherServlet] Context initialization failed

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 95 in XML document from class path resource [spring/spring.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 95; columnNumber: 84; cvc-complex-type.2.4.c: 일치하는 와일드 카드 문자가 엄격하게 적용되지만 'util:properties' 요소에 대한 선언을 찾을 수 없습니다.

문제 원인

스프링 설정 파일에서 xsd 파일 버전이 맞지 않아 발생하는 문제였다.

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:websocket="http://www.springframework.org/schema/websocket"
	xsi:schemaLocation="http://www.springframework.org/schema/beans 
			http://www.springframework.org/schema/beans/spring-beans-4.2.xsd
			http://www.springframework.org/schema/websocket
			http://www.springframework.org/schema/websocket/spring-websocket-4.2.xsd">

웹소켓을 연동하기 위해 spring 4.2.1 release jar를 프로젝트에 포함시킨 것은 제대로 했으나 spring 설정 파일에서 xsd를 읽어올 때는 4.2.xsd 파일을 참조하도록 하였다. 이 둘의 버전이 맞지 않기 때문에 서버 구동시 프로젝트에 포함된 jar 가지고는 xsd를 읽을 수 없어 자동으로 인터넷에서 4.2 버전의 xsd 파일을 찾는 것 같다. 

이를 해결하기 위해서는,

1.프로젝트에 포함된 jar와 spring 설정 파일의 xsd 버전을 똑같이 맞춰주든지

2.그냥 설정 파일의 버전을 없애고 빌드하면 된다

문제 해결

Spring 설정 파일의 xsd 버전을 삭제했다. 

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:websocket="http://www.springframework.org/schema/websocket"
	xsi:schemaLocation="http://www.springframework.org/schema/beans 
			http://www.springframework.org/schema/beans/spring-beans.xsd
			http://www.springframework.org/schema/websocket
			http://www.springframework.org/schema/websocket/spring-websocket.xsd">

참고 사이트

- schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/beans/spring- beans-4.1.5.xsd - stackoverflow

- Spring schemaLocation fails when there is no internet connection - stackoverflow

- 인터넷에 연결 안되면 Spring Framework 에러 발생. - 민서네집 티스토리 블로그

출처: https://insomniachaos.tistory.com/161 [DEV_NOTE]

String, StringBuffer, StringBuilder의 장단점 및 차이점

자바에서 String과 StringBuffer, StringBuilder의 차이점을 알아본다.

이들의 공통점은 모두다 String(문자열)을 저장하고 관리하는 클래스들이다.

어떤 차이점이 있을까?

String과 (StringBuffer, StringBuilder)의 차이점은 String은 immutable(불변)하고 StringBuffer, StringBuilder는 mutable(가변)하다는 점이다.

쉽게 말해서 String은 new 연산을 통해 생성되면 그 인스턴스의 메모리 공간은 절대 변하지 않는다.

그래서 + 연산이나 concat을 이용해서 문자열에 변화를 줘도 메모리 공간이 변하는 것이 아니라 새로운 String객체를 new로 만들어서 새로운 메모리 공간을 만드는 것이다.

이렇게 새로운 문자열이 만들어지면 기존의 문자열은 가비지 콜렉터에 의해 제거되야 하는 단점(언제 제거될지 모름)이 있다.

또한 이러한 문자열 연산이 많아질 때 계속해서 객체를 만드는 오버헤드가 발생하므로 성능이 떨어질 수 밖에 없는 단점이 있다. (+연산에 내부적으로 char배열을 사용함)

대신 String 클래스의 객체는 불변하기 때문에 단순하게 읽어가는 조회연산에서는 타 클래스보다 빠르게 읽을 수 있는 장점이 있다. (+불변하기 때문에 멀티쓰레드환경에서 동기화를 신경쓸 필요가 없음(장점))

결론 => String 클래스는 문자열 연산이 적고 조회가 많을 때 멀티쓰레드 환경에서 사용하면 좋음.

StringBuffer와 StringBuilder 클래스는 String과 다르게 mutable(변경가능)하다.

즉 문자열 연산에 있어서 클래스를 한번만 만들고(new), 연산이 필요할 때 크기를 변경시켜서 문자열을 변경한다.

그러므로 문자열 연산이 자주 있을 때 사용하면 성능이 좋다!

심지어 StringBuffer와 StringBuilder 클래스의 메서드들이 같으므로 호환(?)이 가능하다.

그렇다면 StringBuffer와 StringBuilder의 차이는 무엇일까?

차이점은 StringBuffer는 멀티쓰레드환경에서 synchronized키워드가 가능하므로 동기화가 가능하다. 즉, thread-safe하다.

StringBuilder는 동기화를 지원하지 않기 때문에 멀티쓰레드환경에서는 적합하지 않다.

대신 StringBuilder가 동기화를 고려하지 않기 때문에 싱글쓰레드 환경에서 StringBuffer에 비해 연산처리가 빠르다.

결론 => 문자열 연산이 많을 때 멀티쓰레드환경에서는 StringBuffer, 싱글쓰레드또는 쓰레드를 신경쓰지 않아도 되는 환경에서는 StringBuilder를 사용하는 것이 적절하다.

다시 한번 정리하면,

String클래스는 불변 객체이기 때문에 문자열 연산이 많은 프로그래밍이 필요할 때 계속해서 인스턴스를 생성하므로 성능이 떨어지지만 조회가 많은 환경, 멀티쓰레드 환경에서 성능적으로 유리합니다.

StringBuffer클래스와 StringBuilder클래스는 문자열 연산이 자주 발생할 때 문자열이 변경가능한 객체기 때문에 성능적으로 유리합니다.

StringBuffer와 StringBuilder의 차이점은 동기화지원의 유무이고 동기화를 고려하지 않는 환경에서 StringBuilder가 성능이 더 좋고, 동기화가 필요한 멀티쓰레드 환경에서는 StringBuffer를 사용하는 것이 유리합니다.

* StringBuffer와 StringBuilder는 성능으로 따졌을 때 2배의 속도차이가 있다고 하지만 참고사이트의 속도 차이 실험 결과 append()연산이 약 1억6천만번 일어날 때 약 2.6초의 속도차이를 보인다고 합니다.

(String은 +연산이 16만번이상 넘어가게 되면 10초이상 걸리면서 못 쓸정도의 성능을 보입니다.)

따라서 문자열연산이 많지만 엄청나게 일어나지 않는 환경이라면 StringBuffer를 사용해서 thread-safe한 것이 좋다는 생각입니다.

* JDK1.5이상부터 String에서 +연산으로 작성하더라도 StringBuilder로 컴파일하게 만들어 놨다지만 여전히 String클래스의 객체 생성하는 부분을 동일하므로 StringBuffer,StringBuilder 사용이 필요함.

+ StringBuffer, StringBuilder의 경우 buffer size를 초기에 설정해야하는데 이런 생성, 확장 오버로드가 걸려 버퍼사이즈를 잘못 초기화할 경우 성능이 좋지 않을 수 있음.

+ String클래스가 컴파일러분석단계에서 최적화될 가능성이 있기때문에 간혹 성능이 잘나오는 경우도 있음. 문자열 연산이 많지 않은 경우는 그냥 사용해도 무방.

런타임에서 문자열조합이 많아질 경우 String은 여전히 성능이 아주 안좋기 때문에!

+, concat을 사용하는 사고(?)를 치면 안된다. 특히 현업에서....

출처: https://jeong-pro.tistory.com/85 [기본기를 쌓는 정아마추어 코딩블로그]