@RequestParam 필수값 제거 @RequestParam으로 파라미터를 받을때 값이 들어오지 않으면 에러가 발생한다. 필수값이 아닌경우 null 가능으로 지정해줄 수 있다. (required = false를 추가하자. default는 required = true이기 때문에 명시하지 않으면 필수값이 아닐 경우 에러가 발생한다. Before @RequestParam MultipartFile file After @RequestParam(required = false) MultipartFile file
상황 PathVariable으로 파라미터를 이메일형식 (ID@test.com) 으로 받을 경우 에러가 발생한다. controller에서 RequestMapping 또는 putMapping 등 url을 지정해줄때, 위 처럼 { }안의 파라미터를 사용할 수 있다. 이때 '.' 이 들어갈때 . 뒷부분이 짤려나가는 경우가 있다. 해결방안 @PutMapping("/register/{exam:.+}") public void exam(@PathVariable String exam) { } 예를들어 email이 exam@exam.com 이라고 하면, 위 url은 .../register/exam@exam 이 된다. 하지만 :.+ 을 써주면 모든 이메일이 파라미터로 들어오게 된다.
스프링의 빈 오브젝트 스프링의 애플리케이션 컨텍스트는 IoC 컨테이너로써, 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이다. 스프링은 여러 번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다. getBean() 메소드를 실행할 때마다 같은 오브젝트를 돌려준다. 스프링은 기본적으로 별다른 설정을 하지않으면, 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다. 왜 스프링은 싱글톤으로 빈을 만들까? 스프링이 주로 적용되는 대상은 자바 엔터프라이즈 서버환경이다. 자바 엔터프라이즈 서버환경이란, 서버 하나당 최대로 초당 수십에서 수백번씩 브라우저나 다른 시스템으로부터의 요청을 받아 처리할 수 있는 높은 성능이 요구되는 환경이다. 만약 매번 클라이언트에서 요청이 올때마다 각 로직을 담당하는 오브젝트를..
org.apache.commons.fileupload.FileUploadException 에러발생 에러내용: Failed to parse multipart servlet request; nested exception is org.apache.commons.fileupload.FileUploadException: the request was rejected because no multipart boundary was found 스크립트 총 10개의 파일업로드할 input을 생성하였다. $.ajax({ url: '/v1/model/modelInsertSave', data: formData, type: "POST", contentType: false, processData: false,..var formDat..
일반적은 프로그램의 흐름 1) mian() 메소드와 같이 프로그램이 시작되는 지점에서 다음에 사용할 오브젝트를 결정한다. 2) 결정한 오브젝트를 생성한다. 3) 만들어진 오브젝트에 있는 메소드를 호출한다. 4) 그 오브젝트 메소드 안에서 다음에 사용할 것을 결정하고 호출한다. 이 4가지 단계가 반복적으로 일어난다. 이런 프로그램 구조에서 각 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다. 모든 오브젝트가 능동적으로 자신이 사용할 클래스를 결정하고, 언제 어떻게 그 오브젝트를 만들지를 스스로 결정한다. 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조이다. 제어의 역전 제어의 역전이란, 위에서 설명한 일반적인 프로그램의 제어 흐름 구조가 뒤바뀌는 것이라고 설명할..
의존관계란? 두 개의 클래스 또는 모듈이 의존관계에 있다고 말할 때는 항상 방향성을 부여해줘야한다. A가 B에게 의존하고있다. B가 변하면 A에 영향을 미친다. B의 기능이 추가, 변경이 일어나면 그 영향이 A로 전달된다. A에서 B에 정의된 메소드를 호출해서 사용하는 경우다. B에 새로운 메소드가 추가되거나 기존 메소드의 형식이 바뀌면 A도 그에따라 수정되거나 추가돼야 한다. B의 형식은 그대로지만 기능이 내부적으로 변경되면 결과적으로 A의 기능이 수행되는 데도 영향을 미친다. 방향성이 있다. B는 A의 변화에 영향을 받지 않는다. A가 인터페이스 B에게 의존하고있다. 인터페이스 B가 변하면 A에게 영향을 주겠지만, 중요한 것은 인터페이스 B를 구현한 클래스가 변하더라도 A에게 영향이 주지 않는다는 사..