struts-config.xml에서의 설정으로는 동적으로 바뀌는 파라메터를 넘겨줄 수 없다.

그래서, 액션 클래스에서의 특별한 처리를 요구하는 데, 다음중 한 방법을 사용하면 된다.

1.  ActionFoward 객체 직접 생성

   다음과 같이 ActionForward객체를 생성하여 리턴한다.
   return new ActionForward("/index.html?param=" + paramValue, true);

   파라메터가 많을 경우 코드가 지저분해지고 번거러울 수 있다.

   
   

2. ActionMapping객체를 통한 ActionFoward객체 생성

   대부분의 경우 이같은 방법으로 포워드시킨다.

   excute() 메소드에서 전달 받은 ActionMapping 객체를 이용한다.
   ActionForward forward = mapping.findForward("success");
   ActionForward redirect

   = new ActionForward(forward.getName(), forward.getPath()
   + "?param=" + paramValue, true );

   return redirect;

   
   

3. ActionRedirect 클래스 활용

   org.apache.struts.action.ActionRedirect 클래스를 import시켜서 사용한다.
   ActionRedirect redirect = new ActionRedirect( mapping.findForward("success") );
     redirect.addParameter("param", paramValue);
   return redirect;
   * 주의 : 이 방법은 struts 1.2.7 버전 부터 가능하다.

이 글은 스프링노트에서 작성되었습니다.

 IoC(Inversion of Controll)는 우리말로 제어의 역행 쯤 되시겠다. 그렇다면 제어가 역행됬다는 것은 무슨 뜻인가?

지금까지 객체를 생성하고 각 객체 간의 의존관계(생성하고 머 그런거)를 제어하는 권한은 우리 개발자들에게 있었다. 하지만 서블릿, EJB가 등장하면서 제어권이 서블릿과 ejb를 관리하는 컨테이너에게로 넘어가 버렸다. 개발자들이 서블릿과 ejb를 직접 생성하고 싶어도 이 객체들은 직접 생성하여 제어할 수 없고 객체 생성에 대한 제어권이 컨테이너에게 넘어가면서 객체의 생명주기를 관리하는 권한또한 컨테이너들이 전담할 수 밖에 없게 되었다. 제어권 역전 현상이란 바로 이것을 의미하며, 스프링도 컨테이너처럼 이런 현상(?)을 이용하고 있다. 즉, 스프링 역시 내부에 IoC개념, 객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 제공하고 있다.

스프링은 POJO(Plain Old Java Object : 개발자에 의해 생성/관리되는 평범한 객체 되시겠다.)를 관리하는 컨테이너 역할을 가지고 있다. 즉, 개발자에 의해 정의된 객체(POJO)들을 xml설정에 따라 애플리케이션 시작과 동시에 생성하고 관리하여 주기때문에(기본적으로 그러하다) 컨테이너의 기능상 장점과 POJO 만의 장점을 함께 누릴 수 있는 것이다.
이것이 스프링의 IoC, 역행제어이다.

다음 편에 계속..-_-

'역행 제어'
이 압박감 심한 단어 때문에 어려운 내용일꺼야 지레 겁부터 먹었는데
알고보면 역행제어란 그리 어려운 개념이 아니었습니다.
공부하면서 항상 느끼는 거지만
용어들... 너무 압박감이 심하네요ㅠ

이 글은 스프링노트에서 작성되었습니다.

멱등은 동일한 작업을 어떤 부작용도 없이 한 번이고 두 번이고 계속해서 할 수 있다.

멱등이라는 말은 여러가지 의미로 사용된다. HTTP/서블릿 환경에서 이 말은 동일 요청은 서버에 어떤 잘못된 결과를 야기하지 않고 두 번이상 이루어질 수 있다는 의미이다. 동일 요청은 동일 응답을 가져야 한다는 의미가 아님을, 요청으로 어떤 부작용도 발생하지 말아야 한다는 의미가 아님을 유의해야 한다.

HTTP 스펙 1.1에서는 GET, HEAD, PUT은 멱등이라고 정의하고 있다. 물론 개발자가 멱등이 아닌 doGet()을 작성할 수도 있지만 권장되지는 않는다. POST는 HTTP 스펙 1.1에 의하면 멱등이 아니다.

HTTP GET은 말 그대로 무엇인가를 서버로부터 가져오는 것이지, 서버에 수정을 가하기 위한 것이 아니다. GET은 HTTP 스펙에 따르면 멱등 메소드이다. GET은 어떤 부작용(bad side effect)없이 여러 번 실행할 수 있다.

POST는 반대로 멱등 메소드가 아니다. POST로 전송되는 몸체의 정보는 트랜잭션을 위한 것이면, 이는 되돌릴 수 있는 성질의 것이 아니다. 이런 이유 때문에 doPost()를 구현할 때 유의해야 한다.

-HEAD FIRST Servlet & JSP

컴퓨터를 포맷하고 새롭게 개발환경을 구축하던중에
이클립스를 설치하고 실행하려할 때

JVM terminated. Exit code=-1
.........................
..........(중략)........
..........................
-Xms40m
-Xms512m

이런 류의 경고창이 튀어나왔다.
정확한 답을 찾을 수는 없었지만 메모리 설정에 문제가 생긴 듯 하다.-_-
eclipse가 설치된 폴더에서 eclipse.ini 파일을 연 후

-Xms40m
-Xms512m

이라고 되있는 부분을

-Xms128m
-Xms256m

이라고 고친 후 실행시키면 된다.

JNDI 설정으로 오라클 resource를 사용 하려했을 때 네이밍 예외가 발생하였다.
server.xml 파일을 찾기 위해 톰캣을 설치한 폴더의 server.xml에서 resource를 등록하고
실행을 하였더니 아래와 같은 에러가 발생하였다.

이유인 즉슨, 이클립스에서는 서버(톰캣 등)에 대한 설정들을 별도로 관리하고 있기 때문에
톰캣 폴더의 server.xml에 등록을 하여도 반응을 하지 않는다.

server.xml 파일의 수정은 이클립스의 관리를 받는 녀석한테서 이루어져야 한다.
이클립스의 Project Explorer에서 Servers항목을 열어보면 서버관련 설정파일을 볼 수 있다.
필요에 따라 수정, 등록을 하고 서버를 재가동 시키면 된다.
(때에 따라 곧바로 반영이 안될때가 있는데, 이클립스를 닫았다가 다시 실행하면 된다.)
또는, 자신의 workspace안에 있는 Servers 폴더를 열어서 수정해주어도 된다.