hwannnn

정적 리소스 처리 Servlet 설정 (정적 리소스 처리를 아파치로 하지 않는 경우) 일반적으로 DispatcherServlet을 *.do와 같은 url을 매핑하여 로직을 통한 동적인 리소스를 처리하고, 정적인 리소스는 DefaultServlet으로 처리한다. DefaultServlet에 대한 설정은 톰캣의 web.xml에 설정되어 있으며, *.jsp 요청에 대한 처리를 담당하는 JspServlet도 설정되어있다. // DefaultServlet 설정 <servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> ​ // JspServlet 설정

뷰 인스턴스 라이프싸이클 라이프싸이클 속성에는 크게 인스턴스 생성 / 부착 / 갱신 / 소멸로 나눌 수 있고, 세부적으로는 아래 그림과 같이 beforeCreate, created, beforeMount, mounted 등 8가지로 나뉜다. beforeCreate 인스턴스 생성 후, 가장 먼저 실행되는 라이프싸이클 단계 해당 단계에서는 아직 인스턴스에 data와 methods 속성이 정의되어 있지 않다. 또한, 돔과 같은 화면 요소에도 접근 할 수 없다. created 인스턴스의 data와 methods 속성 등이 정의된 후에 실행되는 라이플싸이클 단계 단, 아직 인스턴스가 화면에 부착되지 않았기 때문에, template 요소에 정의된 돔 요소에는 접근할 수 없다. 주로 서버에 데이터를 요청하여 받아오는 로직을 수행하기에 좋다. beforeMount template 속성에 지정한 마크업 내용을 화면에 그리기 위해 render() 함수로 변환하고, el 속성에 지정한 돔에 인스턴스를 부착하기 전에 호출되는 라이플싸이클 단계 mounted el 속성에서 지정한 돔에 인스턴스가 부착되고 난 후에 실행되는 라이플싸이클 단계 돔 요소에 접근할 수 있으므로, 화면 요소를 제어하는 로직을 수행하기 좋다. 다만, 돔에 인스턴스가 부착되자마자 실행되기 때문에 하위 컴포넌트나 외부 라이브러리의 화면 요소가 그려지는 시점이 다를 수있다. $nextTick()을 활용하여 해결할 수 있다. beforeUpdate el 속성에서 지정한 화면 요소에 인스턴스의 속성들이 치환되는 라이플싸이클 단계 치환 된 값은 뷰 반응성을 위해 감시되고, 이를 데이터 관찰이라고 한다. 따라서, 해당 단계는 관찰하고 있는 데이터가 변경되면 가상 돔으로 화면을 다시 그리기 전에 실행된다. 변경 예정인 새 데이터에 접근 할 수 있지고, 변경 예정인 데이터 값과 관련된 로직을 미리 넣을 수 있

@ExceptionHandler: 언제 어떻게 동작하는가. @RequestParam이나 @Pathvariable, @RequestBody 등 요청 파라미터를 매핑하는 과정에서 에러가 발생했을 시, 즉 Controller에서 @RequestMapping 메소드가 실행되기전에 에러가 발생해도도 ExceptionHandler가 동작할까? ex) @RequestParam int a 일 때, a에 String 값을 넘기는 경우. 결론은 동작한다. ExceptionHandler가 동작하는 부분을 찾아보기 위해 DispatcherServlet의 doDispatch() 메소드를 살펴봤다. 아래 메소드를 보면 try ~ catch로 묶인 부분을 보면, request에 대해 handler를 가져와 실행되는 모든 과정에서 exception이 발생하는 경우 catch절에서 잡히게된다. 에러가 발생하여 catch절 온다면 위임할 exception을 담아둔다. 마지막으로 processDispatchResult에서 핸들러 메소드 실행 결과를 처리한다. protected void doDispatch(HttpServletRequest req, HttpServletResponse res) { try { processedRequest = checkMultipart(req); multipartRequestParsed = (processedRequest != req); // 매핑가능한 handler 가져오기 mappedHandler = getHandler(processedRequest); ... ​ HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler()); ... ​ // p

slf4j - logback 설정 정리 @ 스프링은 자체적으로 JCL을 사용 -> slf4j + logback으로 셋팅 spring-core는 내부적으로 JCL을 사용하는데, 문제는 JCL이 실제 로거를 선택하는 시점이 런타임 시점이라서 대상 클래스를 불러오거나 오버헤드가 발생할 수 있다고 한다. 그런데 slf4j는 이런 문제들을 해결해준다. ​ 1. slf4j + logback 디펜던시를 추가한다. logback-classic 안에는 logback-core와 slf4j-api가 포함되어있다. <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.11</version> </dependency> 2. slf4j로 전환하기 위해서 spring과 jcl의 의존성을 제거한다. spring-core에서 jcl 디펜던시를 제거 <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.3.14.RELEASE</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> spring 내부

자바 로깅 프레임워크 (log4j, logback, slf4j) @ Log4j log4j는 로깅을 수행하는 로깅 구현체다. 1. 주요 기능 및 특징 속도에 최적화되었다. 멀티 스레드 환경에 안전하다. 계층적 로그 설정 및 처리할 수 있다. 6가지의 계층적 로그 레벨 파일, 콘솔, 원격 서버, 이메일 등 다양한 형태로 로그를 기록할 수 있다. 단, 로그에 대한 파일 입출력시 오버헤드가 발생 할 수 있다. 개발 중간에 로그 설정을 변경하면, 서버를 재시작해야한다. 2. 주요 구조 Appender : 파일, 콘솔, 원격 서버 등 로그를 기록할 위치를 지정한다. ConsoleAppender : 콘솔에 로그를 남긴다. FileAppender : 파일에 로그를 남긴다. RollingFileAppender : 로그의 크기가 일정 용량이 되면 다른 파일에 남긴다. DailyRollingFileAppender : 하루 단위로 파일에 로그를 남긴다. SMTPAppender : 이메일에 로그를 남긴다. Layout : 기록할 로그의 패턴을 지정한다. Logger : 로깅일 일어나는 부분을 그룹화하여, 필요한 그룹의 로그만 출력하도록 지정한다. 3. 로그 레벨 FATAL < ERROR < WARN < INFO < DEBURG < TRACE 순으로 6가지의 레벨이 있다. 좌측으로 갈수록 좁은 범위의 크리티컬한 로그 레벨을 의미하고, 우측으로 갈수록 넓은 범위를 로그 레벨을 의미한다. DEBURG로 설정하는 경우, FATAL / ERROR / WARN / INFO / DEBURG 레벨의 로그들을 기록한다. @Logback log4j와 마찬가지로 로깅을 수행하는 로깅 구현체다. logback은 log4j 개발자가 기존의 log4j를 대체하기 위해 개발한 로깅 프레임워크다. log4j를 토대로 만들어서 더 높은 성능과 안정성을 보장할 수 있다

자바스크립트 True and False 자바스크립트는 모든 데이터를 T/F 형태롤 나눌 수 있다. 거짓 같은 값 => false undefined null false 0 NaN “” : empty string 참 같은값 => true 위의 6가지 경우를 제외한 모두 모든 객체. valueOf() 메서드 호출시에도 false를 반환하는 객체도 참 같은 값 빈 배열도 참 같은 값 " "과 같은 공백 문자열 문자열 “false”

jdk 버전 업그레이드시 이슈사항 정리 이슈사항 powermock > javassist jdk 8을 사용할 때, powermock 라이브러리 버전에 이슈가 있다. powermock 안에 javassist라는 라이브러리에서 문제가 있는데, 이 라이브러리는 Java Bytecode를 조작하는 라이브러리로 버전에 따라 jdk 8 클래스의 Bytecode와 호환되지 않는다. javassist-3.18.1.GA부터 호환이 되지만, jdk 8을 호환하기 위한 많은 버그들이 수정된 버전은 3.19.0.GA부터라고 한다. 참고1 / github.com/jboss-javassist 참고2 / stackoverflow spring-asm spring 3.0에서 jdk 8을 사용할 때, lambda 식을 사용하면 이슈가 발생한다. spring-asm이란 라이브러리는 위에서 말한 javassis와 같이 Java Bytecode를 조작하는 라이브러리이다. 따라서 jdk 8의 Bytecode를 조작하는데 이슈가 있는 것 같다. 원래 spring 3.x는 jdk 1.7까지를 지원하고, jdk8은 spring 4.x부터 완전히 호환이 된다고 한다. 하지만 모든 소스가 안되는 것은 아니고 lambda와 같은 jdk 8 syntax는 사용하지 않는다면 문제가 발생하지 않는다. spring 3.2.9 부터는 jdk 8 bytecode를 인식할 수 있지만, 완전히는 아니다. 완전하게 인식하는 버전은 spring 4.0-M1이다