Context : <%= request.getContextPath() %> <BR>
ex) http://localhost:8080/board/list.jsp
return => /board ( 프로젝트 context path 만 가져온다 )
El(표현언어) 사용시 : ${pageContext.request.contextPath}
URL : <%= request.getRequestURL() %> <BR>
URI : <%= request.getRequestURI() %> <BR>
ex) http://localhost:8080/board/list.jsp
return => /board/list.jsp ( 프로젝트 context path와 파일 경로까지 가져온다 )
Path : <%= request.getServletPath() %> <BR>
전달 파라미터 : <%=request.getQueryString()%>
전달 파라미터 Map으로 return : <%=reqeust.getParameterMap()%>
String u = javax.servlet.http.HttpUtils.getRequestURL(request).toString();
javax.servlet.ServletRequest 를 참조하시면 될 것 같습니다.
그 중에 getParameterNames()를 이용해서 parameter명을 Enumeration 으로 저장한 후
Enumeration 내 값을 루프문을 이용해서 추출 하면서 getParameter 메소드를 이용해서 추출 하시면 됩니다.
StringBuffer sb = new StringBuffer();
for (Enumeration en = request.getParameterNames(); en.hasMoreElements(); ){
String key = (String)en.nextElement();
sb.append ( key + "=" + request.getParameter(key) + "&");
}
String paramStr = sb.toString();
paramStr = paramStr.substring(0, paramStr.length()-1);
현재 페이지를 가져올 경우
Tomcat 5.5 이후 forward 된 jsp 에서 request.getRequestURL() 의 값이 이상해진 경우
forward 된 jsp 페이지에서 최초의 브라우저 또는 클라이언트 프로그램으로 부터 호출될 때 사용되었던 URL을 구하기 위해 request.getRequestURL() 이나 request.getRequestURI() 를 사용했던 페이지들 중 tomcat 을 5.0에서 5.5 로 업그레이드 한 이후에 출력값이 달라지는 문제가 발생함을 경험하신 분들이 계실겁니다.
이는 Tomcat 5.5.7 버전부터 getRequestURL() 의 구현이 바뀌었기 때문인데(bug fix), 더이상 최초의 URL 을 넘겨주지 않고 forward 된 jsp 페이지의 URL을 넘겨주도록 되었습니다.
해결책부터 적는다면 5.5.7 이후부터는 getRequestURL() 대신에
request.getAttribute("javax.servlet.forward.request_uri"); <br />
를 사용하면 됩니다.
좀 더 자세한 내용은 wiki 에 작성해 둔 http://www.potatosoft.com/wiki/wiki.php/TOMCAT5#s-9 을 참고하시기 바랍니다.
하나더 include 된 페이지 uri가져올경우
<%= request.getAttribute( "javax.servlet.include.request_uri" ) %>
를 사용
추가로
이렇게 5개 항목이 있음.
forward 와 include 2개가 있음.
request.getAttribute("javax.servlet.include.query_string")
request.getAttribute("javax.servlet.include.path_info")
request.getAttribute("javax.servlet.include.servlet_path")
request.getAttribute("javax.servlet.include.context_path")
request.getAttribute("javax.servlet.include.request_uri")
-------------------------------------------------------------------------------------------------------------------------
서블릿 2.4는 RequestDispatcher forward() 호출 동안에 특별한 정보를 제공하도록 다섯가지 새로운 요청 속성(attribute)을 추가하였다. 서블릿으로 forward()하면, 서블릿 컨테이너는 타겟 서블릿이 최초 호출된 것인것 처럼 패스 환경을 바꾼다. getRequestURI()와 getContextPath(), getServletPath(), getPathInfo(), getQueryString()는 모두 getRequestDispatcher() 메소드에 전달된 URI에 기초하여 정보를 리턴한다. 그러나, 어떤 경우에는 forward()된 타겟 서블릿이 원래 호출 URI를 알 수 있어야 한다. 이것을 위해, 서블릿 2.4는 다음의 요청 속성을 추가하였다:
javax.servlet.forward.request_uri
javax.servlet.forward.context_path
javax.servlet.forward.servlet_path
javax.servlet.forward.path_info
javax.servlet.forward.query_string
포워드된 서블릿에서 getRequestURI()는 항상 타겟 서블릿의 패스를 리턴하지만, 원래의 패스를 얻고자 한다면 request.getAttribute("javax.servlet.forward.request_uri") 를 호출할 수 있다. 예외 상황: forward()가 getNamedDispatcher()에 의해 발생한 경우, 원래 패스 속성이 바뀌지 않기 때문에 이 속성들은 세팅되지 않는다.이 속성들은 서블릿 2.2에 다음의 요청 속성들이 추가된 것을 상기시켜준다:
javax.servlet.include.request_uri
javax.servlet.include.context_path
javax.servlet.include.servlet_path
javax.servlet.include.path_info
javax.servlet.include.query_string
그러나 이것들은 forward() 속성과 반대로 동작한다. include()에서는, 패스 속성이 바뀌지 않기 때문에 include 속성들은 타겟 서블릿 패스 속성에 접근할 수 있는 뒷문(backdoor) 역할을 한다. 패스 속성이 바뀌어 forward 속성이 원래 패스 속성으로의 뒷문(backdoor) 역할을 하는 forward()와 비교해 보라. 그렇다, 매우 복잡하다. 서블릿이 내부적인 dispatch 메카니즘으로서 URI를 사용하면, 이러한 복잡성은 해결된다. (역자주 : 기준이 되는 페이지가 어떤 것이냐의 차이점인 것으로 생각된다. forward는 기준 페이지가 변하므로 기존의 페이지의 패스를 알기 위해 위의 상수들이 필요하고, include는 기준 페이지가 변하지 않으므로 include되는 페이지의 실제 패스를 알기 위해 include 상수들이 필요한 것이다)
이러한 복잡성은 RequestDispatcher와 필터사이의 상호작용에서도 존재한다. 필터가 포워드 된 요청을 호출해야 할까? 포함된 요청은? <error-page> 메카니즘을 통해 호출된 URI의 경우는 어떨까? 서블릿 2.4 이전에는 이러한 의문들이 공개된 이슈로 남겨졌다. 현재 서블릿 2.4는 이런 것들을 개발자의 몫으로 남겨두었다. 배포 지시자에 <dispatcher> 요소를 새로 추가하여, 그곳에 REQUEST 그리고 FORWARD, INCLUDE, ERROR와 같은 값들을 설정할 수 있다. 또한 <filter-mapping>에 <dispatcher> 사항들을, 다음과 같이, 얼마든지 추가할 수 있다:
<filter-mapping>
<filter-name>Logging Filter</filter-name>
<url-pattern>/products/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
이것은 필터가 클라이언트로부터의 직접 요청과 포워드 요청에까지 적용되어야 한다는 것을 말한다. INCLUDE와 ERROR 값을 추가하면, 필터가 인클루드 요청과 <error-page> 요청에 대해서도 적용되어야 한다는 것을 말한다. 원하는 바를 섟고 비교해보라. 아무런 <dispatcher> 요소를 설정하지 않으면, 디폴트는 REQUEST이다. (역자주: 예전에는 포워드된 페이지에 대해서는 필터를 적용시키지 못했는데, 즉 서블릿 2.4의 REQUEST만이 적용가능했지만, 필터마다 이것을 따로따로 설정할 수 있으니 사용할 곳이 참 많을것 같다)
RequestDispatcher 변화의 마지막은 request.getRequestDispatcher() 호출에, 최초로, 상대 패스를 허용한 것이다. 패스는 현재 호출 패스에 상대적으로 해석될 것이다. 큰 변화는 아니지만, 동료(sibling) 서블릿으로 디스패치될 때 유용할 것이다.
======================================================================================================================
Servlet
절대경로
getServletContext().getRealPath("/")); // 웹서버의 Document Root
ex) getServletContext().getRealPath("/WEB-INF/web.xml"));
or
config.getServletContext().getRealPath("/");
or
getServletConfig().getServletContext().getRealPath("/");
or
request.getSession().getServletContext().getRealPath("/");
======================================================================================================================
Java
절대경로
new File("").getAbsolutePath() : 절대경로
new File("").getCanonicalPath() : 상대경로
'프로그래밍 > JSP' 카테고리의 다른 글
Math.round() 를 이용한 소숫점 반올림 (0) | 2016.07.20 |
---|---|
JSP 페이지 이동 4가지 방법 및 특성 (0) | 2016.01.28 |