공식문서는 Dispatcher Servlet에 대해서 뭐라고 할까요?
이번글은 공식 문서에서 소개하는 DispatchServlet에 대해 정리했습니다.
정리 범위 : Locale ~ Logging
Locale
Most parts of Spring’s architecture support internationalization, as the Spring web MVC framework does. DispatcherServlet lets you automatically resolve messages by using the client’s locale. This is done with LocaleResolver objects.
Spring의 대부분의 아키텍처 구성 요소는 Spring 웹 MVC 프레임워크와 마찬가지로 국제화(internationalization)를 지원합니다.
DispatcherServlet은 클라이언트의 로케일(locale)을 사용하여 메시지를 자동으로 해석할 수 있도록 합니다. 이는 LocaleResolver 객체를 사용하여 수행됩니다.
When a request comes in, the DispatcherServlet looks for a locale resolver and, if it finds one, it tries to use it to set the locale. By using the RequestContext.getLocale() method, you can always retrieve the locale that was resolved by the locale resolver.
요청이 들어오면, DispatcherServlet은 로케일 리졸버(locale resolver)를 찾고, 이를 발견하면 해당 로케일 리졸버를 사용하여 로케일을 설정하려고 시도합니다. RequestContext.getLocale() 메서드를 사용하면 항상 로케일 리졸버가 해석한 로케일을 가져올 수 있습니다.
In addition to automatic locale resolution, you can also attach an interceptor to the handler mapping (see Interception for more information on handler mapping interceptors) to change the locale under specific circumstances (for example, based on a parameter in the request).
자동 로케일 해석 기능 외에도, 특정 조건(예: 요청의 특정 매개변수를 기반으로)에 따라 로케일을 변경할 수 있도록 핸들러 매핑(handler mapping)에 인터셉터(interceptor)를 연결할 수도 있습니다. 핸들러 매핑 인터셉터에 대한 자세한 내용은 Interception 섹션을 참조하세요.
Locale resolvers and interceptors are defined in the org.springframework.web.servlet.i18n package and are configured in your application context in the normal way. The following selection of locale resolvers is included in Spring.
로케일 리졸버와 인터셉터는 org.springframework.web.servlet.i18n 패키지에 정의되어 있으며, 애플리케이션 컨텍스트에서 일반적인 방식으로 구성됩니다. 다음은 Spring에서 제공하는 로케일 리졸버의 일부입니다.
Time Zone
In addition to obtaining the client’s locale, it is often useful to know its time zone. The LocaleContextResolver interface offers an extension to LocaleResolver that lets resolvers provide a richer LocaleContext, which may include time zone information.
클라이언트의 로케일(locale)을 얻는 것 외에도, 종종 해당 클라이언트의 시간대(time zone)를 아는 것이 유용합니다.
LocaleContextResolver 인터페이스는 LocaleResolver의 확장 기능을 제공하며, 이를 통해 리졸버가 보다 풍부한 LocaleContext를 제공할 수 있도록 합니다. 이 LocaleContext에는 시간대 정보(time zone information)가 포함될 수도 있습니다.
When available, the user’s TimeZone can be obtained by using the RequestContext.getTimeZone() method. Time zone information is automatically used by any Date/Time Converter and Formatter objects that are registered with Spring’s ConversionService.
사용 가능한 경우, 사용자의 시간대(TimeZone)는 RequestContext.getTimeZone() 메서드를 사용하여 얻을 수 있습니다.
또한, 시간대 정보는 Spring의 ConversionService에 등록된 모든 날짜/시간 변환기(Date/Time Converter) 및 포매터(Formatter) 객체에서 자동으로 사용됩니다.
Spring에서는 클라이언트의 로케일(Locale)뿐만 아니라 시간대(TimeZone) 정보도 함께 확인할 수 있습니다. 이를 위해 LocaleResolver의 확장 기능인 LocaleContextResolver 인터페이스를 사용할 수 있으며, 이를 통해 보다 풍부한 로케일 정보(LocaleContext)를 제공할 수 있습니다.
만약 LocaleContextResolver를 사용할 경우, 클라이언트의 시간대 정보도 함께 처리할 수 있으며, 해당 시간대는 RequestContext.getTimeZone() 메서드를 통해 가져올 수 있습니다.
또한, Spring의 ConversionService에 등록된 날짜 및 시간 변환기(Date/Time Converter)와 포매터(Formatter)들은 이 시간대 정보를 자동으로 활용하여 올바르게 변환을 수행합니다. 이를 통해 애플리케이션에서 사용자의 시간대에 맞는 날짜 및 시간 처리가 가능해집니다.
Header Resolver
This locale resolver inspects the accept-language header in the request that was sent by the client (for example, a web browser). Usually, this header field contains the locale of the client’s operating system. Note that this resolver does not support time zone information.
이 로케일 리졸버(locale resolver)는 클라이언트(예: 웹 브라우저)가 보낸 요청(request)의 accept-language 헤더를 검사합니다. 일반적으로 이 헤더 필드는 클라이언트 운영 체제의 로케일(locale)을 포함합니다. 이 로케일 리졸버는 시간대(time zone) 정보를 지원하지 않는다는 점에 유의해야 합니다.
Cookie Resolver
This locale resolver inspects a Cookie that might exist on the client to see if a Locale or TimeZone is specified. If so, it uses the specified details. By using the properties of this locale resolver, you can specify the name of the cookie as well as the maximum age. The following example defines a CookieLocaleResolver:
이 로케일 리졸버(locale resolver)는 클라이언트에 존재할 수 있는 쿠키(cookie)를 검사하여 로케일(Locale) 또는 시간대(TimeZone)가 지정되어 있는지 확인합니다.
만약 해당 정보가 존재하면, 해당 로케일 또는 시간대 정보를 사용합니다.
이 로케일 리졸버의 속성(properties)을 사용하면, 쿠키의 이름(name)과 최대 유효 기간(maximum age)을 지정할 수 있습니다.
다음은 CookieLocaleResolver를 정의하는 예제입니다.
<bean id="localeResolver" class="org.springframework.web.servlet.i18n.CookieLocaleResolver">
<property name="cookieName" value="clientlanguage"/>
<!-- in seconds. If set to -1, the cookie is not persisted (deleted when browser shuts down) -->
<property name="cookieMaxAge" value="100000"/>
</bean>
cookieName 기본값: 클래스 이름 + "LOCALE" 설명: 쿠키의 이름(Name)
cookieMaxAge 기본값: 서블릿 컨테이너의 기본값 설명: 클라이언트에서 쿠키가 유지되는 최대 시간. -1로 설정하면 쿠키가 지속되지 않으며, 브라우저가 종료될 때까지 유효함.
cookiePath 기본값: / 설명: 쿠키의 가시성을 사이트의 특정 부분으로 제한함. cookiePath가 지정되면, 해당 경로 및 그 하위 경로에서만 쿠키가 유효함.
Session Resolver
The SessionLocaleResolver lets you retrieve Locale and TimeZone from the session that might be associated with the user’s request. In contrast to CookieLocaleResolver, this strategy stores locally chosen locale settings in the Servlet container’s HttpSession. As a consequence, those settings are temporary for each session and are, therefore, lost when each session ends.
SessionLocaleResolver는 사용자의 요청과 연관된 세션(session)에서 Locale과 TimeZone을 가져올 수 있도록 합니다.
CookieLocaleResolver와 달리, 이 전략은 선택된 로케일(Locale) 설정을 서블릿 컨테이너(Servlet container)의 HttpSession에 저장합니다.
그 결과, 이러한 설정은 각 세션마다 임시적으로 유지되며, 세션이 종료되면 해당 설정도 사라집니다.
Note that there is no direct relationship with external session management mechanisms, such as the Spring Session project. This SessionLocaleResolver evaluates and modifies the corresponding HttpSession attributes against the current HttpServletRequest.
또한, Spring Session 프로젝트와 같은 외부 세션 관리 메커니즘과 직접적인 연관은 없습니다.
SessionLocaleResolver는 현재 HttpServletRequest에 대해 해당 HttpSession 속성을 평가하고 수정합니다.
Locale Interceptor
You can enable changing of locales by adding the LocaleChangeInterceptor to one of the HandlerMapping definitions. It detects a parameter in the request and changes the locale accordingly, calling the setLocale method on the LocaleResolver in the dispatcher’s application context. The next example shows that calls to all *.view resources that contain a parameter named siteLanguage now changes the locale. So, for example, a request for the URL, www.sf.net/home.view?siteLanguage=nl, changes the site language to Dutch. The following example shows how to intercept the locale:
LocaleChangeInterceptor를 하나의 HandlerMapping 정의에 추가하면 로케일(Locale) 변경 기능을 활성화할 수 있습니다.
이 인터셉터는 요청(request)에서 특정 파라미터를 감지하여 로케일을 변경하며, 이를 통해 DispatcherServlet의 애플리케이션 컨텍스트에서 LocaleResolver의 setLocale 메서드를 호출합니다.
다음 예제에서는, 모든 *.view 리소스에 대해 siteLanguage라는 파라미터가 포함된 요청을 감지하여 로케일을 변경합니다.
예를 들어, 다음과 같은 URL 요청이 있을 경우: www.sf.net/home.view?siteLanguage=nl 해당 요청은 사이트의 언어를 네덜란드어(Dutch)로 변경합니다. 다음 예제에서는 로케일 변경을 가로채는 방법을 보여줍니다.
<bean id="localeChangeInterceptor"
class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
<property name="paramName" value="siteLanguage"/>
</bean>
<bean id="localeResolver"
class="org.springframework.web.servlet.i18n.CookieLocaleResolver"/>
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="interceptors">
<list>
<ref bean="localeChangeInterceptor"/>
</list>
</property>
<property name="mappings">
<value>/**/*.view=someController</value>
</property>
</bean>
Themes
You can apply Spring Web MVC framework themes to set the overall look-and-feel of your application, thereby enhancing user experience. A theme is a collection of static resources, typically style sheets and images, that affect the visual style of the application.
Spring Web MVC 프레임워크의 테마(theme)를 적용하면 애플리케이션의 전체적인 룩앤필(look-and-feel)을 설정할 수 있으며, 이를 통해 사용자 경험을 향상시킬 수 있습니다.
테마는 정적 리소스(예: 스타일 시트 및 이미지) 모음으로, 애플리케이션의 시각적 스타일(visual style)에 영향을 줍니다.
as of 6.0 support for themes has been deprecated theme in favor of using CSS, and without any special support on the server side.
버전 6.0부터 테마(theme) 지원이 더 이상 권장되지 않으며(deprecated),서버 측의 특별한 지원 없이 CSS를 사용하는 방식이 권장됩니다.
Defining a theme
To use themes in your web application, you must set up an implementation of the org.springframework.ui.context.ThemeSource interface. The WebApplicationContext interface extends ThemeSource but delegates its responsibilities to a dedicated implementation. By default, the delegate is an org.springframework.ui.context.support.ResourceBundleThemeSource implementation that loads properties files from the root of the classpath. To use a custom ThemeSource implementation or to configure the base name prefix of the ResourceBundleThemeSource, you can register a bean in the application context with the reserved name, themeSource. The web application context automatically detects a bean with that name and uses it.
웹 애플리케이션에서 테마를 사용하려면, org.springframework.ui.context.ThemeSource 인터페이스의 구현을 설정해야 합니다.
WebApplicationContext 인터페이스는 ThemeSource를 확장하지만, 해당 기능을 전담 구현체(dedicated implementation)에 위임(delegate)합니다.
기본적으로, 이 위임 객체는 org.springframework.ui.context.support.ResourceBundleThemeSource이며,
이는 클래스패스(classpath) 루트에서 프로퍼티(properties) 파일을 로드하여 테마를 관리합니다.
커스텀 ThemeSource 구현을 사용하거나 ResourceBundleThemeSource의 기본 이름 접두사(base name prefix)를 설정하려면,
애플리케이션 컨텍스트에서 예약된 이름 themeSource를 가진 빈(bean)을 등록하면 됩니다.
웹 애플리케이션 컨텍스트는 자동으로 해당 이름을 가진 빈을 감지하고 이를 사용합니다.
When you use the ResourceBundleThemeSource, a theme is defined in a simple properties file. The properties file lists the resources that make up the theme, as the following example shows:
ResourceBundleThemeSource를 사용할 경우, 테마는 간단한 프로퍼티 파일(properties file)에서 정의됩니다.
이 프로퍼티 파일에는 테마를 구성하는 리소스들이 나열되며, 다음 예제에서 이를 보여줍니다.
styleSheet=/themes/cool/style.css
background=/themes/cool/img/coolBg.jpgThe keys of the properties are the names that refer to the themed elements from view code. For a JSP, you typically do this using the spring:theme custom tag, which is very similar to the spring:message tag. The following JSP fragment uses the theme defined in the previous example to customize the look and feel:
프로퍼티의 키(keys)는 뷰(view) 코드에서 테마 요소를 참조하는 이름입니다.
JSP에서 이를 사용할 때는 보통 spring:theme 커스텀 태그를 사용하며, 이는 spring:message 태그와 매우 유사한 방식으로 동작합니다. 다음 JSP 코드 조각은 이전 예제에서 정의된 테마를 사용하여 애플리케이션의 룩앤필(look and feel)을 맞춤 설정하는 방법을 보여줍니다.
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<html>
<head>
<link rel="stylesheet" href="<spring:theme code='styleSheet'/>" type="text/css"/>
</head>
<body style="background=<spring:theme code='background'/>">
...
</body>
</html>
By default, the ResourceBundleThemeSource uses an empty base name prefix. As a result, the properties files are loaded from the root of the classpath. Thus, you would put the cool.properties theme definition in a directory at the root of the classpath (for example, in /WEB-INF/classes). The ResourceBundleThemeSource uses the standard Java resource bundle loading mechanism, allowing for full internationalization of themes. For example, we could have a /WEB-INF/classes/cool_nl.properties that references a special background image with Dutch text on it.
기본적으로, ResourceBundleThemeSource는 빈(base name) 접두사를 사용하지 않습니다.
그 결과, 프로퍼티(properties) 파일은 클래스패스(classpath) 루트에서 로드됩니다.
따라서, cool.properties 테마 정의 파일을 클래스패스 루트에 위치한 디렉터리(예: /WEB-INF/classes 등)에 배치해야 합니다.
ResourceBundleThemeSource는 표준 Java 리소스 번들(ResourceBundle) 로딩 메커니즘을 사용하므로, 테마의 완전한 국제화(internationalization)를 지원합니다.
예를 들어, /WEB-INF/classes/cool_nl.properties 파일을 생성하여, 네덜란드어 텍스트가 포함된 특정 배경 이미지를 참조하도록 설정할 수 있습니다.
Spring의 ResourceBundleThemeSource는 애플리케이션에서 테마를 정의하고 적용할 수 있도록 하는 기능을 제공합니다. 기본적으로 이 클래스는 특정 접두사(base name prefix)를 사용하지 않으며, 테마와 관련된 프로퍼티(properties) 파일을 클래스패스(classpath) 루트에서 로드합니다.
예를 들어, cool.properties라는 테마를 정의하려면 /WEB-INF/classes/cool.properties에 위치해야 합니다. 이렇게 하면 Spring이 자동으로 해당 테마 파일을 인식하고 사용할 수 있습니다.
또한, ResourceBundleThemeSource는 Java의 표준 리소스 번들(ResourceBundle) 로딩 메커니즘을 사용하기 때문에 국제화(i18n)를 지원합니다. 예를 들어, /WEB-INF/classes/cool_nl.properties라는 파일을 추가하면, 클라이언트의 로케일이 네덜란드(nl)로 설정될 경우 자동으로 해당 파일의 설정이 적용됩니다. 이를 활용하면 국가별 또는 언어별로 서로 다른 스타일을 적용할 수 있습니다.
결과적으로, Spring의 테마 기능을 사용하면 하나의 애플리케이션에서 다양한 언어와 지역에 맞춘 맞춤형 UI를 제공할 수 있으며, 특정 사용자의 로케일에 따라 다른 스타일과 디자인을 적용하는 것이 가능해집니다.
Resolving Themes
After you define themes, as described in the preceding section, you decide which theme to use. The DispatcherServlet looks for a bean named themeResolver to find out which ThemeResolver implementation to use. A theme resolver works in much the same way as a LocaleResolver. It detects the theme to use for a particular request and can also alter the request’s theme. The following table describes the theme resolvers provided by Spring:
앞에서 설명한 대로 테마를 정의한 후에는, 사용할 테마를 결정해야 합니다.
DispatcherServlet은 어떤 ThemeResolver 구현체를 사용할지 확인하기 위해 themeResolver라는 이름의 빈(bean)을 찾습니다.
테마 리졸버(ThemeResolver)는 로케일 리졸버(LocaleResolver)와 매우 유사한 방식으로 동작합니다.
즉, 특정 요청(request)에 대해 사용할 테마를 감지하고, 요청의 테마를 변경할 수도 있습니다.
다음 표는 Spring에서 제공하는 테마 리졸버(ThemeResolver) 목록을 설명합니다.
Spring also provides a ThemeChangeInterceptor that lets theme changes on every request with a simple request parameter.
Spring은 또한 ThemeChangeInterceptor를 제공하며, 이를 사용하면 간단한 요청 파라미터를 통해 매 요청마다 테마를 변경할 수 있습니다.
Multipart Resolver
MultipartResolver from the org.springframework.web.multipart package is a strategy for parsing multipart requests including file uploads. There is a container-based StandardServletMultipartResolver implementation for Servlet multipart request parsing. Note that the outdated CommonsMultipartResolver based on Apache Commons FileUpload is not available anymore, as of Spring Framework 6.0 with its new Servlet 5.0+ baseline.
org.springframework.web.multipart 패키지의 MultipartResolver는 파일 업로드를 포함한 멀티파트(multipart) 요청을 해석하는 전략입니다. 서블릿 기반의 멀티파트 요청을 해석하기 위해, 컨테이너 기반의 StandardServletMultipartResolver 구현체가 제공됩니다.
Spring Framework 6.0부터 Apache Commons FileUpload를 기반으로 한 기존 CommonsMultipartResolver는 더 이상 사용되지 않습니다.
이는 Spring의 새로운 Servlet 5.0+ 환경을 기준으로 한 변경 사항입니다.
To enable multipart handling, you need to declare a MultipartResolver bean in your DispatcherServlet Spring configuration with a name of multipartResolver. The DispatcherServlet detects it and applies it to the incoming request. When a POST with a content type of multipart/form-data is received, the resolver parses the content wraps the current HttpServletRequest as a MultipartHttpServletRequest to provide access to resolved files in addition to exposing parts as request parameters.
멀티파트 처리를 활성화하려면, multipartResolver라는 이름의 MultipartResolver 빈(bean)을 DispatcherServlet의 Spring 설정에 선언해야 합니다.
DispatcherServlet은 해당 빈을 감지하고, 이를 들어오는 요청에 적용합니다.
multipart/form-data 콘텐츠 타입을 가진 POST 요청을 받을 경우, 리졸버는 요청 내용을 해석하고, 현재 HttpServletRequest를 MultipartHttpServletRequest로 래핑(wrap)하여, 요청 파라미터뿐만 아니라 업로드된 파일에도 접근할 수 있도록 합니다.
Spring의 MultipartResolver는 파일 업로드를 포함한 멀티파트(multipart) 요청을 처리하는 기능을 제공합니다.
Spring에서는 Servlet 기반의 StandardServletMultipartResolver를 사용하여 멀티파트 요청을 해석할 수 있다. 이전에는 Apache Commons FileUpload 기반의 CommonsMultipartResolver가 사용되었지만, Spring Framework 6.0부터는 더 이상 지원되지 않습니다.
멀티파트 요청을 처리하려면, Spring 설정에서 multipartResolver라는 이름의 MultipartResolver 빈(bean)을 등록해야 합니다. 이렇게 하면 Spring의 DispatcherServlet이 이를 자동으로 감지하고 멀티파트 요청을 처리할 수 있도록 적용합니다.
클라이언트가 multipart/form-data 형식의 POST 요청을 보내면, Spring의 MultipartResolver가 요청을 해석하고, 기존의 HttpServletRequest를 MultipartHttpServletRequest로 변환합니다. 이를 통해 일반적인 요청 파라미터뿐만 아니라 업로드된 파일에도 접근할 수 있게 됩니다.
멀티 파트는 파일 업로드를 포함하여 다양한 데이터를 동시에 전송하는 방식입니다.
Servlet Multipart Parsing
Servlet multipart parsing needs to be enabled through Servlet container configuration. To do so:
- In Java, set a MultipartConfigElement on the Servlet registration.
- In web.xml, add a "<multipart-config>" section to the servlet declaration.
The following example shows how to set a MultipartConfigElement on the Servlet registration:
서블릿(Servlet) 멀티파트 요청 파싱을 사용하려면 서블릿 컨테이너(Servlet container) 설정을 통해 활성화해야 합니다. 이를 수행하는 방법은 다음과 같습니다:
- Java 코드에서 MultipartConfigElement를 서블릿 등록 시 설정
- web.xml에서 <multipart-config> 섹션을 서블릿 선언에 추가
다음 예제는 서블릿 등록 시 MultipartConfigElement를 설정하는 방법을 보여줍니다.
public class AppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
// ...
@Override
protected void customizeRegistration(ServletRegistration.Dynamic registration) {
// Optionally also set maxFileSize, maxRequestSize, fileSizeThreshold
registration.setMultipartConfig(new MultipartConfigElement("/tmp"));
}
}
이 리졸버(resolver) 변형은 서블릿 컨테이너(Servlet container)의 멀티파트 파서를 그대로 사용하며,
이로 인해 애플리케이션이 컨테이너 구현 차이(container implementation differences)에 노출될 가능성이 있습니다.
기본적으로, 모든 HTTP 메서드에서 multipart/ 콘텐츠 타입을 파싱하려고 시도하지만, 이는 모든 서블릿 컨테이너에서 지원되지 않을 수도 있습니다. 자세한 내용과 설정 옵션은 StandardServletMultipartResolver Javadoc을 참고하세요.
Spring의 StandardServletMultipartResolver는 서블릿 컨테이너가 제공하는 멀티파트 요청 파서를 그대로 사용
하기 때문에, 컨테이너마다 다르게 동작할 가능성이 있습니다. 기본적으로 모든 HTTP 메서드에서 multipart/ 요청을 처리하려 하지만, 일부 컨테이너에서는 이를 지원하지 않을 수 있으므로 컨테이너별 동작 방식을 확인하는 것이 중요합니다.
Logging
DEBUG-level logging in Spring MVC is designed to be compact, minimal, and human-friendly. It focuses on high-value bits of information that are useful over and over again versus others that are useful only when debugging a specific issue.
Spring MVC의 DEBUG 레벨 로깅은 간결하고 최소화되며, 사람이 읽기 쉽게 설계되었습니다.
이 로깅은 반복적으로 유용한 중요한 정보(high-value bits of information)에 초점을 맞추며,
특정 문제를 디버깅할 때만 필요한 기타 정보들은 최소화합니다.
TRACE-level logging generally follows the same principles as DEBUG (and, for example, also should not be a fire hose) but can be used for debugging any issue. In addition, some log messages may show a different level of detail at TRACE versus DEBUG.
TRACE 레벨 로깅은 DEBUG와 동일한 원칙을 따르지만,
모든 문제를 디버깅하는 데 사용할 수 있도록 더 세부적인 정보를 포함할 수 있습니다.
또한, 일부 로그 메시지는 TRACE와 DEBUG에서 서로 다른 수준의 세부 정보를 제공할 수도 있습니다.
Good logging comes from the experience of using the logs. If you spot anything that does not meet the stated goals, please let us know.
좋은 로깅은 실제 로그를 사용한 경험에서 비롯됩니다.
따라서, 위의 목표에 부합하지 않는 부분이 있다면 피드백을 주시기 바랍니다.좋은 로깅은 실제 로그를 사용한 경험에서 비롯됩니다.
Spring MVC의 DEBUG 로깅은 간결하고 최소한의 정보를 제공하여 사람이 쉽게 읽을 수 있도록 설계되었습니다.
반복적으로 유용한 핵심 정보만 기록하며, 특정 문제를 디버깅할 때만 필요한 불필요한 정보는 제외됩니다.
TRACE 로깅은 DEBUG와 동일한 원칙을 따르지만, 더 상세한 정보를 제공하여 모든 문제를 디버깅하는 데 사용할 수 있습니다.
같은 로그 메시지라도 TRACE에서는 더 많은 세부 정보가 출력될 수 있습니다.
결과적으로, Spring MVC의 로깅은 실용성과 가독성을 중시하며, 실제 사용 경험을 바탕으로 개선될 수 있다. 따라서, 로깅 방식이 목표에 맞지 않는다면 피드백을 제공하는 것이 중요합니다.
Sensitive Data
DEBUG and TRACE logging may log sensitive information. This is why request parameters and headers are masked by default and their logging in full must be enabled explicitly through the enableLoggingRequestDetails property on DispatcherServlet.
DEBUG 및 TRACE 로깅은 민감한 정보를 기록할 수 있습니다.
이러한 이유로, 요청 매개변수(request parameters)와 헤더(headers)는 기본적으로 마스킹(masking) 처리되며,
해당 정보를 전체 로그로 기록하려면 DispatcherServlet의 enableLoggingRequestDetails 속성을 명시적으로 활성화해야 합니다.
Spring MVC에서 DEBUG 및 TRACE 로깅은 요청의 민감한 정보를 포함할 수 있기 때문에 기본적으로 보호됩니다.
요청 매개변수(Request Parameters)와 헤더(Headers)는 기본적으로 마스킹(masking) 처리되며, 로그에서 직접 확인할 수 없습니다. 그러나, 필요할 경우 DispatcherServlet의 enableLoggingRequestDetails 속성을 활성화하면 마스킹 없이 요청 데이터를 전체 로그로 기록할 수 있습니다.
이 설정을 변경하면 로그에 요청의 모든 매개변수와 헤더가 포함될 수 있으므로, 보안 위험을 고려하여 신중하게 사용해야 합니다.
The following example shows how to do so by using Java configuration:
다음 예제는 Java 설정(Java configuration)을 사용하여 이를 활성화하는 방법을 보여줍니다.
public class MyInitializer
extends AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected Class<?>[] getRootConfigClasses() {
return ... ;
}
@Override
protected Class<?>[] getServletConfigClasses() {
return ... ;
}
@Override
protected String[] getServletMappings() {
return ... ;
}
@Override
protected void customizeRegistration(ServletRegistration.Dynamic registration) {
registration.setInitParameter("enableLoggingRequestDetails", "true");
}
}
'공식문서' 카테고리의 다른 글
| [Spring Docs] Transaction Management #3 (0) | 2025.03.19 |
|---|---|
| [Spring Docs] Transaction Management #2 (0) | 2025.03.18 |
| Garbage Collector #2 (0) | 2025.03.17 |
| [Spring Docs] DispatchServlet #1 (0) | 2025.03.15 |
| [Spring Docs] Transaction Propagation (0) | 2025.03.14 |
