U've got a minute?

JSP(JAVA Server page)의 특징

1)강력한 이식성 :

2)서버 자원의 효율적인 사용

• 기존 CGI방식의 가장 큰 단점 중의 하나는 바로 프로세스 관리의 어려움으로 인한 서버 자원의 낭비였다고 볼수 있다. 사용자가 웹 서버에 요청을 보내면 서버는 각 요청 당 하난의 프로세스를 생성하고 해당 프로세스를 통해 결과를 생산하면 프로세스가 종료되는 구조를 가지고 있었기 때문이다.

-JSP는 이러한 문제점을 스레드(Thread)기반의 아키텍처(컴퓨터 시스템의 하드웨어 구조)를 사용하여 개선시켰다.

 즉, 최초의 요청이 웹 서버에 들어오면 서버는 그 요청에 맞는 JSP 페이지에 대한 서블릿 인스턴스(자바에서는 클래스로부터 만들어진 객체를 뜻함, 실제 사용 할수 있게 메모리에 생성된 객체를 인스턴스라고 하는 경향이 있다.)

3)간편한 MVC 패턴 적용

• Model : 실제 비즈니스 로직이 들어가는 부분
• View : 사용자에게 보여지는 화면
• Controller : 서블릿, (디자인 패턴)

출처 : [ jsp 2.2&servlet3.0(오정원지음) 내용입니다. ]

일반적인 웹 애플리케이션은 클라이언트/서버 방식으로 이루어진다.

클라이언트는 사용자의 요청을 뜻한다.

서버는

웹서버 : 사용자의 요청을 받아들이고 결과 페이지를 전송담당

애플리케이션서버 : 사용자의 요청을 실질적으로 처리할수 있는 비즈니스 로직 구현담당.

이러한 웹 애플리케이션의 구조를 3-tier(티어)구조라 한다.

출처 : [ jsp 2.2&servlet3.0(오정원지음) 내용입니다. ] & 구글링 이미지 검색

executeQuery() : 결과 값이 발생하여 값을 받아 와야 할때 사용한다.

-select

executeUpdate() : 결과 값을 받아 올 필요가 없을 때 사용한다.

-insert, update, delete

prepareStatement

prepareStatement는 dynamic parsing으로 sql문을 parsing한 후 입력된 해당 값을 parsing된 sql문에 binding하여 실행한다.

dynamic parsing은 sql문을 먼저 parsing하여 입력되는 값이 여러개 일 경우 sql문을 여러번 parsing하지 않고 parsing된 sql문에 원하는 값을 binding하여 사용하므로 자원의 낭비가 적다.

prepareStatement사용 시 PreparedStatement를 사용하여 sql문에 필요한 데이터를 입력 받고 실행 시 발생한 데이터를 ResultSet에 저장한다.

장점 : 값의 binding없이 sql문 만을 parsing하므로 parsing된 sql문의 재사용이 용의하여 자원이 낭비으며 인젝션으로 인한 피해를 줄일 수 있다.

단점 : 무겁다.

createStatement

creatStatement는 static parsing으로 sql문을 parsing할 때 입력된해당 값을 sql문에 binding하여 같이 parsing하여 실행한다.

static parsing은 sql문과 입력된 값을 함께 파싱 하므로 한번 parsing된 sql문을 다른 데이터를 입력하여 사용할 수 없어 해당 서비스에 사용자 수가 많은 경우 메모리 full이 발생할 수 있다.

createStatement사용 시 Statement를 사용하여 sql문에 필요한 데이터를 입력 받고 실행 시 발생한 데이터를 ResultSet에 저장한다.

장점 : 가볍다

단점 : parsing된 sql문 사용 시 입력된 값이 다를 경우 재사용할 수 없으며 자원의 낭비가 발생할 수 있다.

인젝션으로 인한 피해가 발생할 수 있다.

정리 :

prepareStatement 

:dynamic sql parsing 으로 sql문의 재사용이 용의하나 무겁다는 단점이 있다.

createStatement

:static sql parsingd 으로 한번 파싱된 sql문의 데이터값이 다를 경우 재 사용 할수 없으며,

해당 서비스에 사용자 수가 많을 경우 메모리 full이 발생 할수 있다.

가겹다는 장점이 있다.

공통 : 입력 받고 실행으로 발생한 데이터를 ResultSet로 저장한다.

1. Servlet 이란?

 - 자바 플랫폼에서 컴포넌트 기반으로 웹 애플리케이션을 개발 할수 있는 기술.

ex) 이클립스에서 new > 자바(class)를 생성 하듯이 new > servlet 파일(java파일을 생성하지만..)을 생성 할수 있다.

2.컴포넌트란?

-특정 기능을 수행하기 위한 응용시스템을 구축하기 위해 사용되는 s/w단위

3.서블릿 생명주기

     1)init()   초기화 이벤트 : 처음 한번만 실행 (컨테이너는 해당 서블릿을 메모리에서 있는지 확인하여 첫 실행된다.)

     2)service()

         doGet()

         doPost()

     3)destory()     : 종료 이벤트

인터페이스 문법은 알고 있지만 막상 왜 사용 되어야 하는지 개념을 잡고자 정리를 한다.

1.먼저 interface는 다른 클래스의 멤버들과 달리 다음과 같은 제약 사항을 가지고 있다.

-모든 멤버 변수는 public static final 이어야 하며, 이를 생략할수 있다.

-모든 메서드는 public abstract이어야 하며, 이를 생략할수 있다.

2.인터페이스의 추상메서드의 몸통을 구현하는 자손 클래스를 작성해야하는데 이때 인터페이스를 구현한다고 하며 키워드는 implements를 사용한다.

3.인터페이스 이름은 주로 able로 (~를 할수 있는 ) 의미로 파일(인터페이스명)으로 한다.(권장)

ex) playable

4.인터페이스를 구현한 자손 클래스는 인터페이스의 멤버 접근자보다 넓은 범위의 접근제어자를 지정해야 한다.

-interface의 멤버 void a(int a, int b)   //이넘을 자손 클래스에서 구현할때 private void a() 이런식으로 하면 에러가난다.

※ 인퍼페이스를 사용 하는 이유는

확장성과 코드의 유연함이 주 목적

 출처 : http://lng1982.tistory.com/17

Spring에서 DispatcherServlet은 그 자체가 Servlet이기 때문에 1개 이상의 DispatcherServlet을 설정하는 것이 가능합니다.

공통빈 설정 예)

<context-param>

           <param-name>contextConfigLocation</param-name>

           <param-value>/WEB-INF/applicationContext*.xml</param-value>

</context-param>

<listener>

           <listener-class>

           org.springframework.web.context.ContextLoaderListener

           </listener-class>

</listener>

ContextLoaderListener가 생성한 컨텍스트가 root컨텍스트가 되고, DispatcherServlet이 생성한 인스턴스는 root컨텍스트를 부모로 사용하는 자식 컨텍스트가 된다.

이때 자식컨텍스트들은 root컨텍스트가 제공하는 빈을 사용 할 수 있기 때문에

ContextLoaderListener를 이용하여 공통빈을 설정하는 것이다.

참고로..

ContextLoaderListener는 ContextConfigLocation을 명시하지 않으면

/WEB-INF/applicationContext.xml을 설정파일로 사용한다. 이때, 설정파일이 존재 하지 않으면 에러가 발생하니 주의해야 한다.

출처 : http://blog.naver.com/minis24?Redirect=Log&logNo=80097770192

영어 대소문자를 구분한다와 둘다 포함한 것을 구분한다라 생각하면 된다.

예로 들자면,

if(input.equal("a") || input.equal("A"))      // equal은  대소문자 를 모두 써야 한다.

if(input.equalsIgnoreCase("a")          //equalsIgnoreCase일 경우 한가지만 써주면 된다.

많은 서버 프로그램에서 COntent-Dispositon(http 헤더)에 파일 이름을 표시할 때 표준 위반을 하고 있습니다.

첫째, 공백 문자가 들어감에도 불구하고, 따옴표로 묶지 않는 것

Content-Disposition: attachment; filename=this is a picture.png

올바른 표기법)

Content-Disposition: attachment; filename="this is a picture.png"

두번째, ASCII 범위 밖의 글자를 내보낼 때입니다.

MS IE가 2231(?)을 지원하지 않기 때문에 현실적으로 RFC 2047(?)을 써야 합니다.

하지만, 어떠한 경우에도 그냥 8bit 글자를 내보내는 일은 피해야 합니다.

ex) 잘못된 예

Content-Disposition: attachment; filename=그림.png

라고 하면 안됩니다.

다음이 RFC 2231에 따른 방식입니다. 길이가 길지 않다면 RFC 2231이 RFC 2047봗 더 간단합니다.

Content-Disposition: attachment; filename*="UTF-8"%EA%BC.png"

다음은 RFC 2047 방식

Content-Disposition: attachment; filename="="?UTF-8?B?6re466LnBu?="

http가 8bit-clean에 불구하고 위에 적은 것처럼 7bit로 바꿔 주어야 하는 이유는 filename에 쓰인 character encdoing/MIME charset이 알려 주기 위해서 입니다.

정리 하면

1.filename에는 따옴표로 묶어야 합니다.

2.ASCII 범위 밖의 글자가 있을 때에는 character encoding을 표시해 줄수 있는 RFC 2047/2231 방식으로 변환해야 한다.

출처 : http://blog.naver.com/mgcos?Redirect=Log&logNo=50000162802

 <!-- settings
  cacheModelsEnabled="true"  < iBatis 캐싱을 사용할지 여부 지정하는데 사용, 매핑구문에서 캐시 모델 설정해야 한다.>
  enhancementEnabled="true"   < CGLIB에 최적화된 클래스를 통해 적재지연 성능을 향상시킬지의 여부지정>
  lazyLoadingEnabled="true"   <적재지연 사용 여부>
  maxRequests="32"            <비추, request는 SQL 작업을 의마형 최대 요청갯수를 지정한다. 디폴트 512개>
  maxSessions="10"     <비추, 디폴트는 128개 이며, 한번에 10개의 세션만이 가능하도록 설정>
  maxTransactions="5"    <비추, 디폴트 32개, 활성트랜잭션의 갯수>
  useStatementNamespaces="true"  <네임스페이스를 사용해야 시행하도록 한다 디폴트는 false>
  
  <
   위의 비추천 속성은 사용을 권장 하지 않는다. 수정해야 한다면, 항상 maxRequest값 > maxSession > maxTrasaction 이 되도록 한다.
   일반적으로 세 값이 동일하게 유지하게 하는것이 좋다.
   
  >
 
 <sqlMap resource="kr/co/lnj/web/sql/Board.xml"/ -->