나를 정리하는 공간

1.  SLF4J 로깅 처리


세상에는 여러 Logger들이 존재한다. 무엇을 쓸지는 크게 상관없지만 어플리케이션을 개발할때는 한가지 선택 해야하고, 중요한 것은 의존된 라이브러리가 쓰고 있는 Logger도 잘 확인해야 함. 섞어 쓸 수도 있지만, logging을 제어하려면 하나로 통일 되야 좋다.  여기서 내가 쓰고 싶은 Logger로 통일하고 싶다면 방법은 SLF4J이다.


SLF4J는 로깅 Facade입니다. 로깅에 대한 추상 레이어를 제공하는것이고 java로 따지면 interface덩어리 라고 보시면 됩니다. artifact이름도 api라고 부릅니다.


• 사용방법 - pom.xml에 다음과 같은 의존을 추가한다


<dependency>
  <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
  <version>1.7.7</version>
</dependency>




실행 코드는 다음과 같다.


import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Sample {
  final Logger logger = LoggerFactory.getLogger(Sample.class);
  public void run() {
  logger.debug("debug");
  logger.info("info");
  }
}




하지만 이를 실행하면 다음과 같은 오류가 난다.


SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".SLF4J: Defaulting to no-operation (NOP) logger implementationSLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.




구현체가 없기 때문이다. 여기서 구현체란  commons logging, log4j, java util logging, logback 이런 종류의 로깅 구현체를 말한다. 






2. Logback


여러 구현체가 존재하지만 나는 Logback을 공부해왔고, 우리 프로젝트에 적용하고 싶다. 그 이유는 다음과 같다. 


- system.out.println 한줄 남기는데 io 리소스를 너무 많이 먹어서 시스템이 느려짐
- log4j는 메모리 관리를 따로해서 io쪽에서 메모리를 많이 안먹고 빠르다.
- log4j를 막 쓰다 보니.. system.out.println 만큼 리소스를 먹게 된다..
- 이를 보안하기 위해 logback이 개발 됨




즉, “log4j“에서 제공을 하지 않는 기능 외에 다양한 이점이 있음.


다양한 이점을 더 알고 싶다면 다음을 참고하자!




1) logback의 3가지 컴포넌트


“logback-core“는 말 그대로 핵심 코어 컴포넌트 입니다. “logback-classic“은 “slf4j“에서 사용이 가능하도록 만든 플러그인 컴포넌트 입니다.
“logback-access“는 사용하는 어플리케이션이 “웹 어플리케이션“일 경우 빛을 바라는 컴포넌트 입니다.” HTTP 요청에 대한 강력한 디버깅 기능을 제공 합니다.”


2) Graceful recovery from I/O failures


“Log4j” 같은 경우 “JDBC” , “Socket“등 다양한 “Appender“를 지원 합니다.특히. 대다수의 환경에서는 “File”에 제일 많이 로그를 저장 할 것입니다.
하지만 만약 “파일 서버가 일시적으로 장애가 발생 할경우” , “파일 서버가 복구 될때까지”“어플리케이션을 중지 시켰다가” 다시 파일 서버가 복구되면, 그때 서버를 재기동 할것 입니다. 하지만 “LOGBack“은 “서버 중지 없이, 이전 시점부터 복구를 graceful “하게 지원을 합니다.


3) Automatic removal of old log archives


대부분 환경에서는 “하나의 파일”에 기록하는 것이 아니고, “특정 시간” 또는 “특정 파일 사이즈”로 “Rolling” 해서 “Archiving“을 할 것입니다.
하지만 “Archiving된 로그 파일“을 계속 유지하지 않고, 일정 기간 지나면 서비스에 부담을 주지 않기 위해서” 파일을 삭제 할것 입니다.
이럴경우 “Crontab” 또는 다른 삭제 스케줄러를 설정 또는 개발을 할것입니다.“LOGBack“은 “maxHistory“라는 설정 정보를 통해서 주기적으로 “Archive”
파일을 자동 삭제 합니다.“maxHistory“의 값이 “12“일 경우, “12개월 이후 삭제 하라는” 뜻입니다.


4) Lilith
“Lilith“은 “현재 발생하는 로그 이벤트에 대한 상태 정보를 볼수 있도록 지원 하는
뷰어” 입니다.“log4j“를 지원하는 “chainsaw” 와 비슷한 기능을 합니다. 다만 차이점은 “Lilith” “Large data“를 지원 합니다.


5) Conditional processing of configuration files


빌드를 해본 사람이라면 아실듯 합니다. 빌드시 제일 골치가 아픈 것이 “config” 정보 와 “log file path” 입니다.
이유는 어플리케이션이 구동하는 환경이 “로컬, staging, cbt” 마다 틀리기 때문 입니다. 이런점을 해결 하기 위해서 “Maven Filter” 기능을 사용 하거나, “JVM -D환경변수“를 통해서 각 환경 마다 선택적으로 “log 설정파일“을 선택하도록 구성을 할 것입니다.
“LOGBack“은 이런 이슈를 좀더 “Graceful“하게 지원을 합니다. “JSTL” 같이 분기 스크립트 (<if>, <then> and <else>)를 제공해서 하나의 파일에서 다양한 빌드 환경을 제공 하도록 지원을 합니다.


6) Filters


“Filter” 기능은 “Log4j“에서 지원하는 기능입니다. 주 기능은 “로깅을 남길지 , 말지를”핸드링 할수 있는 기능 입니다.
좀더 이해를 돕기 위해서 “UseCase“를 설명 드리겠습니다.


만약 “A“라는 사용자에게 비즈니스적으로 문제점이 발견이 되었습니다.이럴경우는 “logical exception“이기 때문에 원인을 잡기가 쉽지가 않습니다.
또한 현재 “운영 서버“의 “Log LEVEL“이 “ERROR“일 경우 로그를 확인 할수가 없을것입니다. 더욱이  “운영 서버 logical exception“은 “staging” 환경과 데이터가 틀리기 때문에실제 운영 로그를 확인하지 않고서는 재현을 할수가 없습니다.


그래서 “운영 서버의 로그 레벨“을 “DEBUG“로 수정합니다. 하지만 로그는 보이지만 전체 사용자가해당이 되기 때문에 로그 데이터를 분석하기가 어렵습니다.
이럴 경우 “Filter“를 사용해서 “다른 사용자“는 “ERROR” 레벨을 유지하고 ,"A” 사용자만 “DEBUG“로 설정을 하면, 분석하는데 많은 도움을 받을 수 있습니다.


7) SiftingAppender


“SiftingAppender“는 “Filter“의 기능과 유사하면서 다른 기능을 제공 합니다 “로그 파일을 특정 주제별로 분류“를 할 수 있도록 합니다.
예를 들어서 “HTTP Session“별로 로그 파일을 저장한다거나, “사용자별“로 별도의 로그파일을 할 수 있습니다.


8) Logback-access, i.e. HTTP-access logging with brains, is an integral part of logback


위에서 언급했듯이 “logback-access“는 “웹 어플리케이션” 사용시 유용한 툴로써 제공 됩니다.특히나 요새는 전통적인 “HTML” 출력이 아닌 “REST 서버“로써의 역할을 많이 합니다. 이럴 경우 “HTTP 디버깅“을 제공 합니다.




3. Logback 실습 


<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context</artifactId>
  <version>3.2.4.RELEASE</version>
</dependency>


하지만 spring-context는 jarkarta commons logging을 사용하고 있습니다. 실제 이렇게 두면 commons-logging이 의존성에 추가 됩니다. 여기서는 logback을 쓰려고 하니 관련라이브러리는 제거합니다.


** 제거하는 방법


     1) pom.xml









2) Dependency Hierarchy -> commons-logging 우클릭 -> exclude maven artifact





3) ok





4) pom.xml에 추가 됬는지 확인










5)  logback 은 logback-core, logback-classic, logback-access의 3개의 모듈이 있습니다. core는 classic과 access의 공통라이브러리입니다. maven repository를 쓴다면 classic만 추가하면 관련 라이브러리가 추가 됩니다.


<dependencies>
  <dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.1.2</version>
  </dependency>
</dependencies>


이것만 사용하면 기본적인 Log는 사용 가능하다. 


import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.core.util.StatusPrinter;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


public class Tutorial {
  private static final Logger logger = LoggerFactory.getLogger(Tutorial.class); 
 // Logger은 꼭 private static이 붙어야 한다. getLogger(클래스명.clss) 적어라.


  public static void main(String[] args) {
  logger.trace("trace");
  logger.debug("debug");
  logger.info("info");
  logger.warn("warn");
  logger.error("error");
  }
}


** Logger들은 Tree Hierarchy 구조로 level을 적용 받을수 있다.








TRACE > DEBUG > INFO > WARN


ALL : TRACE와 같음 나중에 확장을 위한것으로 보임.
TRACE : TRACE, DEBUG, INFO, WARN, ERROR
DEBUG : DEBUG, INFO, WARN, ERROR
INFO : INFO, WARN, ERROR
WARN : WARN, ERROR
ERROR : ERROR
OFF : 출력하지 않음


여기까지 표준이다. 하지만, 좀 더 기능을 확장하고 싶다면 logback.xml을 작성해야 한다.




Logback.xml


<?xml version="1.0" encoding="UTF-8"?>
<configuration> //logback이 구동될때 logback 상태를 확인할 수 있습니다.
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
  <layout class="ch.qos.logback.classic.PatternLayout">
  <Pattern>%d{HH:mm} %-5level %logger{36} - %msg%n</Pattern>
  </layout>
  </appender>


  <logger name="example.logback.level.grandparents" level="TRACE"/>
//example.logback.level.grandparents 이하 모든 Logger들의 level은 TRACE라는 설정입니다.


  <logger name="example.logback.level.grandparents.parents.children" level="INFO"/>
//example.logback.level.grandparents.parents.children 이하 모든 Logger들의 level은 INFO라는 설정입니다.


  <root level="DEBUG">
             <appender-ref ref="STDOUT" />
  </root>
// 모든 대상에 STDOUT Appender를 적용하고 level이 DEBUG이하인것만 처리로 설정됩니다.
</configuration>






4. Appender
Event마다 Log를 기록하는 기능은 Appender가 처리합니다. 그래서 Logger는 어떤 appender에 해당이 되어 처리 되는게 중요합니다. Appender를 설정하더래도 log출력에 해당되지 않으면 작동하지 않습니다.  Appender는 출력될 형식을 직접 가지고 있지 않고, 해당 기능은 Layout과 Encoder에 위임을 합니다.




<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
  <!-- encoders are assigned the type
  ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
  <encoder>
  <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
  </encoder>
</appender>


Appender의 종류 - ConsoleAppender (콘솔로 찍음), FileAppender(파일에 로그남김), RollingFileAppender(rolling 정책이용) ,  EventEvaluator(이벤트 기능으로 로그 남김)


1) ConsoleAppender 


<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
  <!-- encoders are assigned the type
  ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
  <encoder>
  <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
  </encoder>
</appender>


PatternLayoutEncoder는 pattern으로 받은 값을 이용해서 PatternLayout을 생성하고 PatternLayoutEncoder는 log message를 byte[]로 변환하는 기능도 포함합니다. 이로써 Appender는 Layout기능과 Encoder기능을 모두 가지게 됩니다. 이것을 이용해서 OutputStreamAppender는 byte[]를 OuputStream에 write하게 됩니다.


2) FileAppender


<!-- Insert the current time formatted as "yyyyMMdd'T'HHmmss" under
  the key "bySecond" into the logger context. This value will be
  available to all subsequent configuration elements. -->
<timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"/>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
       <file>log-${bySecond}.txt</file>
       <append>true</append>
  <!-- encoders are assigned the type
  ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
  <encoder>
  <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
  </encoder>
</appender>


로그가 저장될 file을 선언하고, ConsoleAppender처럼 encoder,pattern을 선언하게 되면, log event를 지정된 file에 저장할 수 있습니다. 이때 파일 포맷중 날짜형식은 java.text.SimpleDateFormat을 따릅니다.


3) RollingFileAppender
롤링 정책 적용. 최대 파일 용량 설정가능


<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
  <file>mylog.txt</file>
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  <!-- rollover daily -->
  <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>
  <timeBasedFileNamingAndTriggeringPolicy
  class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
  <!-- or whenever the file size reaches 100MB -->
  <maxFileSize>100MB</maxFileSize>
  </timeBasedFileNamingAndTriggeringPolicy>
  </rollingPolicy>
  <encoder>
  <pattern>%msg%n</pattern>
  </encoder>
</appender>


<fileNamePattern> 확장자에 .zip을 선언하면 새로운 file 이 생성될때 이전 파일은 .zip으로 압축을 할수 있습니다.


4) EventEvaluator
이벤트 설정. 아래 예는 이메일 설정한 예이다. 이메일 로그 설정 관련 자세한 내용을 보고 싶다면  https://sonegy.wordpress.com/2014/06/03/235/ 출처 참고!


<appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">
  <smtpHost>****</smtpHost>
  <smtpPort>25</smtpPort>
  <to>****</to>
  <to>****</to>
  <from>****</from>
  <subject>PRODUCT-PCS: %logger{20} - %m</subject>
  <layout class="ch.qos.logback.classic.PatternLayout">
  <Pattern>%d{HH:mm} %-5level %logger{36} - %msg%n</Pattern>
  </layout>
</appender>




** 공통으로 적용되었던 Layout 패턴에 대해 알아보자!




• %logger{length}: Logger name의 이름을 축약할 수 있습니다. {length}는 최대 차릿수 입니다.
• %thread: 현재 Thread name
• %-5level: log level -5는 출력 고정폭 값
• %msg: log message %message은 alias
• %n: new line


로그 적용시 에러관련 
https://sonegy.wordpress.com/2014/05/23/how-to-slf4j/


출처: http://madeinjeon.tistory.com/18 [Jeon's blog]
http://souning.tistory.com/7
https://sonegy.wordpress.com/2014/05/23/how-to-slf4j/
https://sonegy.wordpress.com/2014/06/03/235/
https://gs.saro.me/#!m=elec&jn=789

1.  tiles 란?

2.   tiles3로 오면서 설정이 더욱 간단해 졌다. tiles3는 spring3.2 버전 이상부터 쓰일 수 있으니 참고바람.

3.     pom.xml에 3가지 dependency를 추가한다.

4.    tiles를 유동적으로 사용하고 싶다면 다음과 같이 설정한다.  우선 모든 view들은 tiles를 정의한 tiles 설정 파일의  definition들에서

5. 다음은 tiles 설정파일 tills.xml

5. layout.jsp

6. Controller mapping 추가

7. 기본적인 부분 완성!  - header.jsp , footer.jsp, mainTest.jsp 는 커밋해놓았으니 각자 코드를 확인해보기 바란다!

1. 재귀방식 짜봐라

재귀 방식이 특히나 면접에서 두번이나 나올만큼 많이 나왔다.

재귀함수란? 어떤 함수에서 자신을 다시 호출하여 작업을 수행하는 방식의 함수를 의미합니다. 

재귀함수를 작성할 때는 함수내에서 다시 자신을 호출한 후 그 함수가 끝날 때 까지 함수 호출 이후의 명령문이 수행되지 않는 다는 사실과 종료조건이 꼭 포함 되어야한다는 부분을 인지하고 작성하면 무한루프를 방지할 수 있습니다.

function recursive(int n) {

if(n == 0) {

system.out.println("종료");

} 

// 탈출 조건이 반드시 필요하다는 것 - 대부분에 면접에서 이것을 안써서 탈락한듯 하다.

else {

system.out.println("n");

recursive(n-1);

}

}

recursive(10);

2. 선택정렬

3. 링크드리스트

4. 큐 스택

웹개발 경력 2년, 면접을 볼 때 그동안 나왔던 질문과 예상 질문들을 정리해보려 한다.

먼저, 이번은 웹과 데이터베이스에 대한 문제이다.

1. JSP와 Servlet 차이?

- 이건 그 회사 잡플래닛에 있길래 정리해봄

- 정답 : 

JSP와 서블릿은 자바 기반으로 만들어진 웹 프로그래밍 언어

JSP는 페이지 요청이 있을 시에는 최초로 한번 자바 코드로 컴파일 된다.

서블릿과 JSP는 상호 연계되어 JSP에서 정적인 부분을 담당하고, 

서블릿은 보다 동적은 처리를 위한 부분으로 사용되어 보다 효율적으로 작성할 수 있다.

Servlet

JSP

2. ajax?

- 실제로 면접에서 나온 질문이다.

문법 

$.ajax({

url: , //주소

type:, //get방식, post방식

data:, // 파라미터

dataType:, // 받을때 데이터 형식

Async:,    //비동기 통신 플래그

true가 비동기, false가 동기  - 동기는 모든 처리가 끝난 후 다음 처리로 넘어간다.

비동기는 동시에 한다.

sucssess:function(response){

}, // 성공적으로 통신이 이루어졌을 때 처리하고 싶은 함수

error:function(error){

} //  에러가 발생하였을 때 처리하고 싶은 함수

});

결과를 바꾸기 위해서 ajax에서 해야할일?

suncess:function(response) {

$().html("xx); // 바꾼다.

}

3. html doctype?

이 소스를 읽을때 이 웹 문서가 html5로 작성되었음을 알려준다.

웹페이지 문서 종류를 알려주는 선언문

웹페이지 제일 처음에 선언되어야 하는 것

어떤 버전의 html 문서로 작성했는지 브라우저에게 알려줌 - 브라우저가 내용을 올바르게 출력하도록 도와준다.

4. get방식과 post 방식?

1) GET

URL 뒤에 ?를 붙여 구분하는 방식, 여러개일 경우 &로 구분한다.

현재, IE를 제외하고 GET방식으로 데이터를 보내는데 제한이 없다고 한다.

민감한 정보를 전송하면 문제가 발생할 여지가 크다.

2) POST

get과 달리 사용자에게 데이터가 그대로 노출되지 않으며, 전송량에 제한이 없다.

http body에 포함되어 전달됨으로서 파라미터 노출이 안된다.

5. Spring framework?

1) 경량 컨테이너로 자바 객체를 직접 관리한다.

각자의 객체 생성 소멸과 같은 라이프 사이클을 관리하며, 스프링으로부터 필요한 객체를 얻어올 수 있다.

2) 스프링은 POJO 방식의 프레임워크

- 특정한 인터페이스를 구현하거나 상속받을 필요가 없어 기존에 존재하는 라이브러리를 지원하기에 용이하고 객체가 가볍다

3) 제어반전 - 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.

4) 스프링은 의존성 주입을 지원한다. - 각각의 계층이나 서비스들간에 의존성이 존재할 경우 프레임워크가 서로 연결

5) AOP - 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.

Framework : 개발할 때 설계 기본이 되는 뼈대나 구조 / 환경 (문제 영역을 해결한 재사용, 확장 가능한 라이브러리.)

MODEL 1 - REQUEST 요청에 대한 처리, 비지니스 로직 핸들링이 모두 JSP단에서 처리됨

MVC MODEL2 - MVC 구조를 웹에 적용하여 개발하는 방식

SPRING MVC - 

1) DispactherServlet: 모든 requeset를 받는 관문이다. request를 실제로 처리할 controller에게 전달하고 그 결과값을 받아서

view에게 전달하여 적절한 응답을 생성할 수 있도록 흐름을 제어한다.

2) Handler Mapping: request url을 각각 어떤 controller가 실제로 처리할 것인지 찾아주는 역할을 한다.

3) controller - request를 처리한 후 그 결과를 다시 DispactherServlet에게 돌려준다.

4) ModelAndView: controller 처리 결과와 그 결과를 보여줄 view에 관한 정보를 담고 있는 객체이다

5) viewResolver: view 관련 정보를 갖고 실제 view를 찾아주는 역할을 한다.

6) view : controller가 처리한 결과값을 보여줄 view를 생성한다.

출처: http://k9e4h.tistory.com/51 [Kim's :D]

6. Oracle 클러스터 인덱스와 넌 클러스터 인덱스의 차이 

클러스터드 인덱스 : 

실제 DB의 데이터 파일에 정렬되어 있는 상태로 디스크에 저장이 됨

테이블당 한개 

넌클러스터드 인덱스 : 

실제 DB의 데이터 파일에 정렬되지 않는 상태로 디스크에 저장이 됨

테이블당 여러개(249개)

출처: https://m.blog.naver.com/PostView.nhn?blogId=islove8587&logNo=220431192221&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

7. JOIN의 종류

- 카티션 곱(Cartesian Product) 

두 개 이상의 테이블에 대해 연결 가능한 행을 모두 결합하는 조인 방법이며, WHERE 절에서 조인 조건절을 생략하거나 조인 조건을 잘못 설정하여 양쪽 테이블을 연결하여 조건에 만족하 는 행이 하나도 없는 경우에 발생 합니다. 

 예) SELECT * FROM DEPT A, EMP B 

- EQUI JOIN 

 SQL 문에서 가장 많이 사용되는 조인으로 조인 대상 테이블에서 공통 칼럼을 ‘=’ 비교를 통해 같은 값을 갖는 행에 대해서 연결하여 결과를 생성하는 조인 방법입니다. 

 예) SELECT A.name FROM DEPT A, EMP B WHERE A.code = B.code 

- NON-EQUI JOIN 

 조인 조건에서 ‘<’,’>’, BETWEEN a AND b’와 같이 ‘=’ 조건이 아닌 다른 종류의 연산자를 사용 하는 조인 방법입니다.

  예) SELECT A.name FROM DEPT A, EMP B WHERE A.code > B.code

 - OUTER JOIN 

 두 개 이상의 테이블 조인 시 한쪽 테이블의 행에 대해 다른 쪽 테이블에 일치하는 행이 없더 라도 다른 쪽 테이블의 행을 NULL로 하여 행을 Return하는 것이 OUTER JOIN 입니다.연산자 로는 (+)기호를 사용합니다. 

 예) SELECT A.name FROM DEPT A, EMP B WHERE A.code = B.code(+)

 - SELF JOIN 

 하나의 테이블에서 두 개의 칼럼을 연결하여 EQUI JOIN을 하는 방법