개요사실 요즘 전자정부 프레임워크의 프로퍼티 관리법은 잘 모르고..오늘 레거시 전자정부 프레임워크에서 프로퍼티 안의 값의 관리법을 알아버려서 간단하게 쓰려고 한다.우리 회사는 3.10.0 버전을 쓰고있다.지금 회사에서 관리하는 전략전략이라고 거창하게 말할 거 까지는 없고 현재 회사에서는 사실 프로퍼티 관리를 안하고 있다!정확하게 말하면 관리하는 척 하고있었다.실제 프로퍼티에 local, dev, prod라는 프로퍼티 파일은 존재하고 있었기 때문이다.프로퍼티가 있는 것 처럼 보였을 뿐이지 실제 값은 적용되고 있지 않았다.그렇지만 톰캣의 catalina.out을 보면 -Ddeploy.phase=prod 라는 배포 설정이 있는데,이걸 보고 당연히 관리한다는 착각을 불러 일으켰다. 근데 제일 중요한 '적용'은 ..

개요처음에는 세션 관리에 대해 "스프링이 알아서 관리해주는 것" 정도로만 생각했다.하지만 회사에서 인증 서버와 게이트웨이를 직접 구현하게 되면서, 이 '단순하게'는 나에게 크나큰 어려움으로 다가오게 됐다.이 글에서는 내가 직접 구현하면서 알게 된 스프링의 세션 관리 방식과, 스프링 세션(Spring Session)이 스프링 시큐리티(Spring Security)와 어떻게 협력하는지에 대해 정리해보려 한다.세션(Session)이란 뭘까?HTTP는 기본적으로 Stateless(상태 비저장) 프로토콜이다. Stateless란, 서버가 클라이언트의 상태를 기억하지 않는다는 뜻이다. 즉, 클라이언트가 서버에 요청을 보낼 때마다, 서버 입장에서는 "얘가 누구였더라?" 를 알 수 없는 상태가 된다.그렇다면 매번 통신..

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.web.multipart.MultipartException: Current request is not a multipart request] with root cause $http({ method: 'POST', url: Config.serverURL, data: formData, headers: { 'Content-Type': undefined } }). ContentType을 명시하지말라는 말은 있었는데, 이게 진짜 undefined로 명시적으로 지워버려야 되..

스프링으로 개발을 하다보면, api response 객체에는 굳이 담을 것이 없지만 이 api가 성공적인 동작을 했다는것은 클라이언트에게 알려야할 수도 있다. 이럴때는 어떤식으로 만들어야 할까? 보통 API response를 그대로 쓰는 경우, 혹은 이것을 살짝만 매핑해서 쓰는 경우가 많을텐데 이럴때는 응답을 안 보낼수도 없고, 보내야만 한다. public ResponseEntity insertUser(Request request) { // ... if(request.id == null) return new ResponseEntity(HttpStatus.NO_CONTENT); // 오류 메시지도 같이 던지면 좋을거같다. return new ResponseEntity(HttpStatus.OK); } 이렇게..

scope dependency 하위에 포함되는 항목 해당 dependency가 포함되는 범위에 대한 타입 scope 종류 compile : 기본 scope. 미입력시에도 기본 적용 모든 상황에서 포함됨 provided : compile과 유사하게 모든 상황에서 수행된다 하지만, 다른 외부 컨테이너에서 기본 제공되는 API인경우 provided로 지정 시 마지막 패키징할 때 포함되지 않음 예를 들면 tomcat에서 기본적으로 servlet api를 제공하기 때문에 servlet api를 provided로 지정하면 패키징시 제외된다. runtime : 컴파일 시에는 불필요 실행시에 필요한 경우. 런타임 및 테스트 시 classpath에 추가 되지만, 컴파일시에는 추가 되지 않음 test : 테스트시에만 사용..

템플릿 메서드 패턴 - 상속을 통해 기능을 확장해서 사용하는 부분이다. 변하지 않는 부분은 슈퍼클래스에 두고 변하는 부분은 추상 메소드로 정의해둬서 서브클래스에서 오버라이드하여 새롭게 정의해 쓰도록 하는것이다. 단점 : 접근 제한이 많다. 로직마다 상속을 통해 클래스를 만들어야 한다. 관계에 대한 유연성이 떨어진다. 전략 패턴 - 개방 폐쇄 원칙(OCP)를 잘 지키는 구조이면서도 템플릿 메소드 패턴보당 유연하고 확장성이 뛰어난 것이, 오브젝트를 아예 둘로 분리하고 클래스 레벨에서는 인터페이스를 통해서만 의존하도록 만드는 전략 패턴이다. OCP 관점에 보면 확장에 해당하는 변하는 부분을 별도의 클래스로 만들어 추상화된 인터페이스를 통해 위임하는 방식이다. 필요에 따라 컨텍스트는 그대로 유지하면서 전략을 바..