실험에 사용 할 도메인은 Employee class


@SessionAttributes(value="employee") 


SessionAttributes alias은 employee 


출력시 어떤 스코프에 있는지 확인을 위해 RequestScope와 SessionScope 둘다 출력 하도록 하였다.


출력페이지 코드


결과 페이지 <br/>

RequestScope : ${requestScope.employee.name } <br/>

SessionScope : ${sessionScope.employee.name }


실험 1.

세션에 아무것도 없을 때


@Controller

@RequestMapping(value="test/*") 

@SessionAttributes(value="employee")

public class TestController {

@RequestMapping(value="test01")

public String test() {

return "forward:resultpage.jsp";

}

}

 

결과





실험 2.

세션에 데이터가 존재 할 때


@Controller

@RequestMapping(value="test/*") 

@SessionAttributes(value="employee")

public class TestController {

@RequestMapping(value="createEmployee")

public String createSession(HttpSession session) {

Employee emp=new Employee();

emp.setName("created Employee");

session.setAttribute("Employee", emp );

return "forward:resultpage.jsp";

}


@RequestMapping(value="test02")

public String test() {

return "forward:resultpage.jsp";

}

}


결과



전통적인 방법으로 세션에 데이터를 입력하였고 결과는 예상대로였다.



세션에 데이터가 있을 경우 실험1과 동일한 요청을 하였을때 

예상과 다르게 requestScope에도 데이터가 있는 것을 확인하였다.


그래서 결과 페이지를 직접 요청해 보았다.

RequestScope에는 존재하지 않는다.


@SessionAttributes를 이용 할 때에 RequestScope에 데이터가 입력된다.




실험3 


실험2와 동일한 조건에서 Model에 같은 이름으로 설정을 해보자.


@Controller

@RequestMapping(value="test/*") 

@SessionAttributes(value="employee")

public class TestController {

@RequestMapping(value="createEmployee")

public String createSession(HttpSession session) {

Employee emp=new Employee();

emp.setName("created Employee");

session.setAttribute("Employee", emp );

return "forward:resultpage.jsp";

}


@RequestMapping(value="test03")

public String test(Model model) {

Employee emp=new Employee();

emp.setName("new Employee");

model.addAttribute("employee",emp);

return "forward:resultpage.jsp";

}

}



결과


세션에 아무것도 없을 경우이다.



세션에 데이터가 입력되는 것을 확인 할 수 있었다.


세션에 데이터가 입력되는 것을 확인 할 수 있었다.



그렇다면 세션에 데이터가 있는 경우는 어떨까

참고로 createEmployee를 먼저 요청 후 test03을 요청하였을때 결과이다.




세션에 데이터가 있던 없던 별 차이가 없는 듯한 결과가 나왔다.



실험4


메소드 인자로 @ModelAttribute를 사용 할 경우.


@Controller

@RequestMapping(value="test/*") 

@SessionAttributes(value="employee")

public class TestController {

@RequestMapping(value="createEmployee")

public String createSession(HttpSession session) {

Employee emp=new Employee();

emp.setName("created Employee");

session.setAttribute("Employee", emp );

return "forward:resultpage.jsp";

}


@RequestMapping(value="test04") 

 public String  test (@ModelAttribute(value="employee")Employee employee) {

     

return "forward:resultpage.jsp";


 }

}


결과

세션에 데이터가 없을 경우

org.springframework.web.HttpSessionRequiredException: Expected session attribute 'employee'


익셉션이 발생한다.


세션에 데이터가 있을 경우





세션에 데이터가 있고 요청에 name을 추가했을 때

?name=test04


세션에 데이터가 없을 경우 익셉션이 발생 하는 것 말고는  

실험3과 같은 것 같다.


실험5


@ModelAtttibute를 메소드 위에 썻을 경우

실험1 부터 같은 조건을 해보았다.


@Controller

@RequestMapping(value="test/*") 

@SessionAttributes(value="employee")

public class TestController {

@ModelAttribute("employee")

public Employee employee() {

Employee emp=new Employee();

emp.setName("default create Employee");

return emp;

}


@RequestMapping(value="createEmployee")

public String createSession(HttpSession session) {

Employee emp=new Employee();

emp.setName("created Employee");

session.setAttribute("Employee", emp );

return "forward:resultpage.jsp";

}


@RequestMapping(value="test01")

public String test() {

return "forward:resultpage.jsp";

}

}


결과

세션에 데이터가 없을 때


@ModelAttribute 가 달린 메소드가 호출 되는 것 같다.


세션에 데이터가 있을 때를 위해 createEmployee를 요청 하였다.



세션을 만드는 메소드가 같은 컨트롤러에 있어서 그런지 위와 같은 결과가 나왔다.

그래서 컨트롤러를 따로 만들어 세션에 데이터 입력 후 다시해 보았다.



 세션에 데이터가 있을 경우는 앞선 실험들과 같은 결과가 나왔다.



실험6

앞선 실험들을 실험5의 @ModelAttribute가 달린 메소드를 추가해서 다시 해보았다.


결과

실험1 부터 3 까지는 같은 결과나왔다. 


※다만 실험4의 세선에 데이터가 없고 메소드인자로 @ModelAttributes가 사용 된 경우 익셉션이 발생하지 않았다. 




총 정리는 이해가 되면 그 때 추가예정.






추가 내용


org.springframework.web.bind.annotation

Annotation Type SessionAttributes



  • @Target(value=TYPE)
     @Retention(value=RUNTIME)
     @Inherited
     @Documented
    public @interface SessionAttributes
    Annotation that indicates the session attributes that a specific handler uses.

    This will typically list the names of model attributes which should be transparently stored in the session or some conversational storage, serving as form-backing beans. Declared at the type level, applying to the model attributes that the annotated handler class operates on.

    NOTE: Session attributes as indicated using this annotation correspond to a specific handler's model attributes, getting transparently stored in a conversational session. Those attributes will be removed once the handler indicates completion of its conversational session. Therefore, use this facility for such conversational attributes which are supposed to be stored in the session temporarily during the course of a specific handler's conversation.

    For permanent session attributes, e.g. a user authentication object, use the traditional session.setAttribute method instead. Alternatively, consider using the attribute management capabilities of the generic WebRequest interface.

    NOTE: When using controller interfaces (e.g. for AOP proxying), make sure to consistently put all your mapping annotations — such as @RequestMapping and @SessionAttributes — on the controller interfacerather than on the implementation class.

@SessionAttributes를 사용하였을때 requestescope에도 데이터가 남아있었는데 위에 저 부분이 해당사항인 것으로 추정 되어진다.

그리고 사용자 인증 같은 경우에는 맨날쓰던 session.setAttribute를 쓰라고 권고 하는 듯하다.

총평
애매하다 싶으면 다같이 그냥 쓰던거 쓰자.


잘 못 된 부분이나 더 자세한 정보를 가지고 계신분은 댓글 남겨주시면 감사하겠습니다.


CSS에 추가

.ui-autocomplete {

  z-index:2147483647;

}


출처:https://stackoverflow.com/questions/16133654/autocomplete-issue-into-bootstrap-modal

<input type='file' accept='image/*' onchange='openFile(event)'><br>

<img id='output'>

<script>

  var openFile = function(event) {

    var input = event.target;


    var reader = new FileReader();

    reader.onload = function(){

      var dataURL = reader.result;

      var output = document.getElementById('output');

      output.src = dataURL;

    };

    reader.readAsDataURL(input.files[0]);

  };

</script>



실행 예시





출처:http://www.javascripture.com/FileReader

html,body,.container {

    height:100%;

}

.container {

    display:table;

    width: 100%;

    margin-top: -50px;

    padding: 50px 0 0 0; /*set left/right padding according to needs*/

    box-sizing: border-box;

}


.row {

    height: 100%;

    display: table-row;

}


.row .no-float {

  display: table-cell;

  float: none;

}


 Web 서버

- HTTP 프로토콜을 기반으로 하여, Web 클라이언트(브라우저) 부터의 요청을 서비스 하는 기능을 담당하는

프로그램(일반적으로 Apache 많이 사용함)

- Web 서버의 역할은 html, 이미지(jpg, gif.. ), xml 등에 대한 처리를 담당(CGI 프로그램 요청도 처리)

 Web Appication 서버

여러 Web 클라이언트(브라우저) 요구를 Web 서버 혼자 감당하기에는 힘들기 때문에구조적으로 Web

서버의 기능을 분리하기 위해 만들어진 것으로 Web Applicatioin Server(WAS)라고 한다.(일반적으로

Tomcat, Weblogic, WebShpare, Jeus, JBoss 등이 이용된다.)

 Web 서버와 Web Applicatiion 서버의 차이점

- Web 서버와 Web Application 서버는 위의 설명처럼 사용의 목적이 다르다. Web 서버는 html, 이미지들의 요청을 처리하는데 빠르고 , Web Application 서버는 Servlet이나, JSP 비지니스 로직을 수행하는데 적합하다.(웹컨테이너란 이러한 ServletJSP 수행하는 역할을 하는 서버를 말한다.) 그렇다고 Web Application Server html, 이미지들의 요청을 처리하지 못한다는 얘기는 아니다다만 처리 속도가 Web 서버에 비해 느리다는  뿐이다이렇게 서로 다른 강점을 합해서 사용하기 위해 Web 서버와 Web Application 서버를 연동하여 서비스를 하는 것이 대부분이다.

 [참조] JSP 기초 http://cafe.naver.com/tonkjsp/6

 Tomcat

- Tomcat JSP 환경을 포함하고 있는 Servlet 컨테이너

- Servlet 컨테이너는 사용자 입장에서 Servlet 유지하고 호출하여 실행하는 

- Tomcat 크게 3가지로 컨테이너로 구분한다.

 Stand-alone servlet containers(Tomcat 기본 모드)

내장된 웹서버의 기능을 사용하는 

기능면에서 JavaWebServer 부분인 Serlvet 컨테이너와 Java 근간  서버를 사용

 In-process servlet containers

- Servlet 컨테이너는 웹서버 플러그인과 Java 컨테이너 구현

웹서버 플러그인은 웹서버의 주소 공간 내에 JVM 열고  안에서 JAVA 컨테이너가 실행되도록 한다.

다중 스레드의 단일 프로세스 서버에 적당하고 퍼포먼스도 좋지만 확장성에 한계가 있음

 Out-of-process servlet containers

웹서버 플러그인과 웹서버의 외부 JVM에서 실행하는 JAVA 컨테이너 구현

웹서버 플러그인과 JAVA 컨테이너 JVM 몇몇 IPC(보통은 TCP/IP 소켓) 사용해서 통신

- Out-of-process 엔진의 반응 시간은 in-process 만큼 좋지 않지만 out-of-process 엔진은 확장성과 안전성 면은 In-process보다 좋다.

 톰캣 디렉토리 구조

- tomcat 6.0 에서는  그림 처럼 되어 있지 않고 common, server 빠진 상태로 되어 있다.

- common, server 빠진 상태로 정리하면

디렉토리명

기능 설명

bin

여기에는 톰캣 서버의 동작을 제어할  있는 스크립트  실행 파일들이 포함되어 있습니다.

conf

톰캣의 기본적인 설정 파일들이 포함되어 있습니다.

lib

아파치와 같은 다른  서버와 톰캣을 연결해주는 바이너리 모듈들이 포함되어 있습니다.

webapps

톰캣이 제공하는  애플리케이션의 기본 위치입니다.

logs

서버의 로그 파일이 저장되는 디렉토리입니다.

Work

JSP 컨테이너와 다른 파일들이 생성하는 임시 디렉토리입니다.

temp

임시 저장 폴더

위의 그림과 같이 항상 같은 구조를 표준 처럼 유지 되어야 한다. 




요구되는
 형태로  어플리케이션 보관소 생성을 용이하게 하기 위해서 어플리케이션의 "실행파일들( 어플리케이션을 실행할  톰캣이 사용하는 파일들) WAR 형식에서 요구하는 것과 같은 구성으로 정리하는게 편합니다이렇게 하려면 어플리케이션의 "문서 루트 document root" 디렉토리에 다음 내용으로 구성합니다

  • *.html, *.jsp, 등. - 웹 어플리케이션에서 클라이언트 브라우저로 전송이 되는 HTML 과 JSP 페이지와 다른 파일들 (예를 들면 자바스크립트, 스타일시트, 이미지 같은). 대규모 어플리케이션에서 이 파일들을 서브디렉토리 체계로 나누어 놓을 수 있습니다. 그러나 규모가 작은 어플리케이션이라면 보통은 하나의 디렉토리에서 전체를 관리하는 것이 보다 단순하고 쉽습니다.
  • /WEB-INF/web.xml - 웹 어플리케이션의 웹 어플리케이션 배치 설명자 Web Application Deployment Descriptor. 서블릿과 웹어플리케이션을 구성하는 다른 컴포넌트들을 설명하고, 각종 초기화 파라메터들과 서버 기능을 활용하기 위한 컨테이너가 관리하는 보안 제한 구역을 지정하는 XML 파일입니다. 다음 섹션에서 좀 더 자세히 알아보도록 하겠습니다.
  • /WEB-INF/classes/ - 이 디렉토리에는 웹 어플리케이션에서 사용하는 모든 자바 파일(그리고, 관련 자원)이 들어있습니다. 서블릿과 비서블릿 클래스 파일들이며 jar 형태로 묶여있지 않은 것입니다. 패키지가 선언된 클래스라면 /WEB-INF/classes/ 를 기준으로 패키지의 디렉토리를 만들어 구성하면 됩니다. 예를 들어, 클래스명이 com.mycompany.mypackage.MyServlet 라면 파일의 저장경로는 /WEB-INF/classes/com/mycompany/mypackage/MyServlet.class 이 됩니다.
  • /WEB-INF/lib/ - 이 디렉토리에는 웹어플리케이션에서 사용하는 자바 클래스파일을 포함하는 JAR 파일들이 위치합니다. 외부 클래스 라이브러리나 JDBC 드라이버 같은 것들입니다.

톰캣(또는 다른 2.2/2.3 호환 서버)에 어플리케이션을 설치할 때, WEB-INF/classes/ 에 있는 클래스들과 WEB-INF/lib/ 디렉토리에 있는 JAR파일에 있는 모든 클래스들은 같은 웹 어플리케이션에서 사용하는 모든 클래스가 접근가능하게 되어있습니다. 따라서, 만일 이 디렉토리 안에 사용하는 모든 라이브러리 클래스들을 몰아 넣으면 (외부 라이브러리를 사용하는 경우 재배포 권한에 관한 라이센스를 확인하길 바랍니다.), 웹 어플리케이션의 설치가 간단히 끝날 수 있습니다 -- 시스템 클래스패스에 대한 조정(또는 서버에 있는 전체 라이브러리의 설치)도 필요 없습니다.

 톰캣 환경설정(server.xml)

- tomcat에서 주요한 환경설정 파일  하나 입니다.

컴포넌트에 대한 초기 설정 제공

- tomcat 대한 구조를 지정

- server.xml 구조  계층적 엘리먼트

상위의 속성은 자동적으로 하위의 요소에 계승된다예를 들어 <Host> 구성요소 <Logger>  속성은 아무것도 지정하지 않은 경우 <Engine> 구성 요소 <Logger> 설정이 사용된다변경이 필요한 경우에는 <Host> 구성요소 <Logger> 별도의 설정을 함으로서 상위의 설정을 덮어 쓸수 있다.



 server 엘리먼트

tomcat 서버 구성요소의 정의 부분이다기본값은 <server port="8005" shutdown="shutdown"> 되어 있으며포트 8005 감시하고 shutdown 명령어를 접수하도록 설정되어 있다서버에서는 복수의 서비스를 관련 지울  있다.

 service 엘리먼트

tomcat service 구성요소를 정의하고 있다. <service> 뒤에 기술  <Engine> 그것에 관련된 모든 <Connector> 그룹화  것이다기본값은 <Service name="Catalina"> 되어 있다. (name 으로 "Tomcat-Standalone" 설정하는 경우도 있음)

-> 속성

■ name : Catalina라고 하는이름으로 서비스가 정의 되어 있고에러 로그  관리툴은  이름으로 식별한다.

하나의 서버에 복수의 서비스를 정의하는 경우다른 name 속성을 기입할 필요가 있다 .

<Serice> <Engine> 하나 이상의 <Connector> 관련짓는 것이 가능하다. <Service> <Engine> 관계는 1:1

 Engine 엘리먼트

<Engine> servlet 컨테이너의 인스턴스를 표시하며, <Connector>로부터 보내진 요구를 처리한다. <Engine name="Catalina" defaultHost="localhost"> 되어 있다.

-> 속성

■ name : <Engine> 이름을 표시하며에러 로그  관리툴은  이름으로 <Engine> 식별한다.

■ defaulthost : server.xml 정의 되어 있지 않은 <Host> 요구가 있을 경우 발송되는 가상호스트를 지정한다.

<Engine>에는 하나 이상의 <Host> 관련지어져 있다.

 Connector 엘리먼트

요구를 <Engine> 건네 주는 역할을 하는 것이 <Connector>. <Serviced> 하나 이상의 <Connector> 갖을 필요 있음

사용자는 HTTP 또는 HTTP/SSL  여러가지 방법으로 <Engine> 요구를 보낸다이것들의 접속 요건의 처리는 <Connector>

구성요소에 맡겨진다 프로토콜에 대해 복수의 <Connector> 갖는 것으로서 어떤 접속에서 요구가 보내져와도 <Engine>

 동일하게 처리하고 , 응답을 <Connector> 맡길  있다.

tomcat에는 몇개의 표준<connector> 탑재되어 있으며기본값은 HTTP1.1 <Connector> AJP<Connector> 준비되어 .

 DefaultContext 엘리먼트

모든 <Conext> 고통의 정의부기본적으로 설정되어 있지 않다.

 Realm 엘리먼트

보안을 위해 role명과 사용자명비밀번호의 맵핑을 외부의 데이터베이스로 부터 가져오는 장치다. tomcat UserDataBase, Memory, JDBC, JNDI 몇개의 <Realm> 가지고 있다.

 <Realm> 차이는 어디로 부터 정보를 가져왔는가의 차이밖에 없다기본값으로는 UserDataBase이외의 <Realm> 주석 처리되어 무효로 되어 있다.

 Logger 엘리먼트

로그파일의 작성 방법을 설정한다. <Logger> server.xml 구조에서 보듯이 <Engine>레벨에서 설정할  있다.

<Logger className="org.apache.catalina.logger.FileLogger">

prefix="server-log." suffix=".txt"

timestamp="true"/>

위의 <>에서는 tomcat FileLogger 클래스를 사용, prefix, suffix, timestamp 속성에서 로그파일명을 정의하고 있다 경우로그파일은 [server-log.2008_08.txt] 같은 형식으로 $CATALINA_HOMe/log 디렉토리에 출력된다.

 Host 엘리먼트

<Engine> 관련된 가상호스트를 정의한다.. 기본값으로 다음과 같이 되어 있다.

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

가상 호스트명을 "localhost" 설정하고 appBase 속성에서 어플리케이션이 탑재되어 있는 디렉토리를 "webapps" 설정하고 있다별도로 unpackWARs에서는 WAR파일을 전개하고나서 실행할 것인지의 여부를 , autoDeploy 속성에서는 tomcat 기동중에 웹어플리케이션을 배치한 경우에 자동으로 읽어 들일 것인지의 여붜를 설정할  있다.

 Value 엘리먼트

tomcat 특유의 기능이다. <Value> 상위 구성요소로의 필터 처리를 담당한다. <Engine>, <Host>, <Context> 관련짓는 것이 가능하다, Tomat에는 표준으로 다음과 같은 몇개의 <Value> 준비되어 있다.

AccessLogValue

<Valve className="org.apache.catalina.valves.AccessLogValve"

directory="logs" prefix="server-log-" fileDateFormat="yyyy-MM-dd" suffix=".txt"/>

RemoteAccessValve

<Valve className="org.apache.catalina.valves.RemoteAddrValve"

allow="127.0.0.1,192.168.0.1" />

SingleSignOnValue

<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>

RequestDumpValue

<Valve className="org.apache.catalina.valves.RequestDumperValve"/>

- AccessLogValue

$CATALINA_HOME/logs 디렉토리에 server-log-2008-08-04.txt  형식으로 로그파일을 작성한다.

- RemoteAccessValue

접근을 IP주소 단위로 제한한다지정주소에서의 접근을 허가거부를 설정할  있다. <>에서는 로컬 IP주소 192.168.0.1 부터의 접근을 허가하고 있다 RemoteHostValue 사용하면 호스트 단위로 접근제한을 설정할  있다.

- SingleSignOnValue

요구와 응답의 헤더와 쿠키를 <Logger> 설정한 로그파일이 작성된다.

 Context 요소

<Host>에는 웹어플리케이션의 복수개의 <Context> 관련지어져 있다. <Context> 요소에는 웹어플리케이션의 일련의 설정 프로퍼티가 들어간다웹어프리케이션 배치에서 소개 한대로  설정은 웹어플리케이션마다에 설정파일을 가질  있다.

- <Logger> 엘리먼트 사용하는 경우

<Logger className="org.apache.catalina.logger.FileLogger"

directory="logs" prefix="localhost_log." suffix=".txt"

timestamp="true"/>

Logger 잠시보면 로거로 FileLogger라는 클래스를 사용할 것이며디렉토리는 톰캣의

logs 디렉토리를 , 파일명은 localhost_log.yyyy-mm-dd.txt 하겠다는 

속성

설명

backgroundProcessorDelay

 값은 컨텍스트와  자식 컨테이너에서 background process method invoke되는delay 시간을 나타낸다.

 값을 양수로 설정하면 어떤 쓰레드가 분기되어 일정 시간 후에  쓰레드가 해당 host 자식 컨테이너에서 background process method 실행시킵니다

만약 설정하지 않으면 디폴트값인 -1 가지며 음수의 값은 부모 host background processing 정책을 사용한다는 것입니다.

참고로 컨텍스트는 세션을 종료하거나 클래스 리로딩을 위한 모니터링등을 위해background processing 사용합니다.

className

사용할 Java 구현체 클래스의 이름 클래스는 반드시 org.apache.catalina.Context인터페이스를 구현해야 합니다지정하지 않으면 표준값 (아래에 정의됩니다) 사용됩니다

cookies

true(디폴트) 지정하면 클라이언트가 쿠키를 지원하는 경우 세션확인의 통신수단(session identifier communication)으로 쿠키를 사용합니다. false 지정하면 세션확인의 통신수단으로 쿠키 사용을 하지 않고어플리케이션에 의한 URL 다시쓰기(URL rewriting)에만 의존한다는 의미입니다.

crossContext

true 지정하면  어플리케이션에서 ServletContext.getContext() 호출을 통해 가상호스트에서 실행중인 다른 웹어플리케이션에 대한 요청디스패쳐(request dispatcher) 성공적으로 얻을  있습니다보안상의 이유로 false(디폴트) 지정하면getContext() 언제나 null 반환하게 됩니다.

docBase

 웹어플리케이션에 대한 Document Base (Context Root로도 알려져 있습니다디렉토리또는 웹어플리케이션 아카이브 파일의 경로명(웹어플리케이션을 WAR 파일로 직접 실행하는 경우) 나타냅니다 디렉토리나 WAR 파일에에 대한 절대경로명을 지정할 수도 있고 Context 정의된 Host appBase 디렉토리에 대한 상대경로명을 지정할 수도 있습니다

override

true 설정하면 DefaultContext element 관련된 host에서 명백하게 상속받아 사용합니다

기본값으로 Defaultcontext element 사용됩니다

privileged

true 설정하면  컨텍스트는 관리자서블릿(manager servlet) 같은 컨테이너 서블릿을사용할  있습니다.

path

 웹어플리케이션의 컨텍스트 경로(context path) 나타내며 요청 URI 시작부분이 컨텍스트 경로와 같을  해당 웹어플리케이션이  요청을 처리하게 됩니다하나의특정 Host 내의 컨텍스트 경로들은 모두 각각 유일해야 합니다만약 컨텍스트 경로를 스트링("")으로 지정하면 Context  Host 대한 디폴트 웹어플리케이션으로정의된 것입니다디폴트 웹어플리케이션은 다른 Context 들에 해당되지 않는 모든 요청을 처리할 것입니다.

reloadable

true 지정하면, Catalina /WEB-INF/classes/ /WEB-INF/lib  클래스 들의 변경여부를 감시하다가변경이 발견되면 웹어플리케이션을 자동으로 재적재(reload)합니다. 기능은 개발중에는 매우 유용하지만 얼마간의 실행부하(runtime overhead) 발생하므로실제 운영할 용도로 어플리케이션을 배치(deploy) 때는 사용하지 않도록 합니다그러나 이미 배치가 끝난 어플리케이션이라도 Manager 웹어플리케이션을 이용하면필요할  재적재 하도록   있습니다

wrapperClass

 Context 관리할 서블릿 들에 대해 사용할 org.apache.catalina.Wrapper 구현체 클래스의 Java 클래스명입니다지정하지 않으면 표준값이 사용됩니다

from http://jakarta.apache.org

=============================================

저자 : GoodBug (unicorn@jakartaproject.com)

최초 : http://www.jakartaproject.com

=============================================

 서블릿 환경설정 (web.xml)

 CATALINA(톰캣 설치 폴더)/conf/web.xml

 invoker 이용하여 모든 서블릿을 호출할  있는 서블릿을 지정합니다.

<servlet>

<servlet-name>invoker</servlet-name>

<servlet-class>

org.apache.catalina.servlets.InvokerServlet

</servlet-class>

<init-param>

<param-name>debug</param-name>

<param-value>0</param-value>

</init-param>

<load-on-startup>2</load-on-startup>

</servlet>

 서블렛을 사용   있도록 환경을 설정하고 Servlet URL상에서의 접근할  있도록 경로명을 지정합니다.

<servlet-mapping>

<servlet-name>invoker</servlet-name>

<url-pattern>/servlet/*</url-pattern>

</servlet-mapping>

 수정된 Servlet,JSP 페이지가 서버를 재시작안해도 인식이 설정

<servlet>

<servlet-name>jsp</servlet-name>

<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>

<init-param>

<param-name>modificationTestInterval</param-name>

<param-value>0</param-value>

</init-param>

<init-param>

<param-name>development</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>fork</param-name>

<param-value>false</param-value>

</init-param>

<init-param>

<param-name>reloading</param-name>

<param-value>true</param-value>

</init-param>

<init-param>

<param-name>xpoweredBy</param-name>

<param-value>false</param-value>

</init-param>

<load-on-startup>3</load-on-startup>

</servlet>



출처: http://jang8584.tistory.com/72 [개발자의 길]

+ Recent posts