[스프링 3.0] 로깅은 SLF4J를 이용한 Log4J로

스프링을 사용하면 기본적으로 JCL(자카르타 커먼스 로깅)을 사용하게 되는데 JCL이 실제 로거를 선택하는 시점이 런타임이라 클래스로더 문제라던가 런타임시 오버헤드가 생길 수 있는데 이것을 개선한 구현체 SLF4J로 갈아타면 그러너 문제 걱정을 덜 수 있겠습니다. 보너스로 문자열 연결로 발생하는 오버 헤드도 개선할 수 있으며 귀찮은 if문 추가하는 코딩에서 벗어날 수 있는 문법? API?를 제공해줍니다. 그래서인지 스프링도 3.0부터는 본격적으로 spring-core가 의존하는 JCL을 SLF4J로 교체하고 사용하는 예제 및 레퍼런스 설명을 보여주고 있습니다..

갈아타는 방법은 다음과 같습니다.

1. 스프링에서 참조하는 JCL 라이브러리를 빼버리기.
2. JCL-over-SLF4J 추가하기.
3. SLF4J API 추가.
4. SLF4J-log4j 추가.
5. log4j 추가.

이전에 스프링소스 블로그와 레퍼런스에 올라온 방법은 이걸 그대로 메이븐 의존성으로 옮겨적고 있지요.

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${org.springframework.version}</version>
            <exclusions>
                <!– Exclude Commons Logging in favor of SLF4j –>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                 </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${org.slf4j.version}</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>jcl-over-slf4j</artifactId>
            <version>${org.slf4j.version}</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>${org.slf4j.version}</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.15</version>
            <exclusions>
                <exclusion>
                    <groupId>javax.mail</groupId>
                    <artifactId>mail</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>javax.jms</groupId>
                    <artifactId>jms</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.sun.jdmk</groupId>
                    <artifactId>jmxtools</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>com.sun.jmx</groupId>
                    <artifactId>jmxri</artifactId>
                </exclusion>
            </exclusions>
            <scope>runtime</scope>
        </dependency>

1번은 단순히 JCL 라이브러리에 의존할 생각이 없기 때문에 빼버리는 것이고, 그때 JCL에 의존하는 클래스들이 깨질 텐데 그것을 JCL-over-SLF4J를 이용해서 겉은 JCL 같지만 내부에서는 SLF4J API를 호출하도록 일종의 어댑터 나 다리 역할을 해주는 라이브러리를 추가하고, 인터페이스 격인 3. SLF4J API를 추가한 뒤 실제 사용할 로거로 SL4J를 구현한 4. SLF4J-Log4J 라이브러리를 추가합니다. 마지막으로 최종적으로 사용할 로거 5. Log4J를 추가한 것입니다. 이때 Log4J가 불필요하게 참조하는 jmx, mail, jms 등의 라이브러리를 제외시켜줍니다.

만약에 Log4J가 아니라 다른 로거를 사용할 거라면 4번과 5번을 교체하면 될테고 JCL 뿐 아니라 log4j에 대한 직접 호출도 slf4j로 오게 하려면 2번 대신 log4j-over-slf4j을 추가하면 되겠습니다.

굉장히 장황니다. @_@;; 하지만 뭐.. 좋다는데.. 갈아타긴 해야겠죠.

출처: SLF4J in 10 slides, by Ceki Gülcü

위와 같은 설정은 스프링 3.0 예제와 레퍼런스에서 사용하고 있습니다. 정말 장황합니다. 일단 여기서 1, 2번은 필수다 하지만 레퍼런스와 블로그 글에도 나와있듯이 그 이하 3, 4, 5는 Logback이라는 SLF4J API 구현체로 한방 설정이 가능합니다.

logback은 크게 세 가지 모듈로 나뉘는데 그 중에 SLF4J API 구현체인 classic 모듈이 있고, Log4J를 개선한 core 모듈이 있습니다. logback 모듈을 가져오면 위에서처럼 log4j가 끌고오는 부가적인 라이브러리도 없고 깔끔하게 log4j API를 사용할 수 있습니다.

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${org.springframework.version}</version>
            <exclusions>
                <!– Exclude Commons Logging in favor of SLF4j –>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                 </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>jcl-over-slf4j</artifactId>
            <version>${org.slf4j.version}</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>com.springsource.ch.qos.logback.classic</artifactId>
            <version>0.9.9</version>
        </dependency>

따라서 굳이 Log4J가 아닌 다른 로거로 갈아탈 계획이 없다면 이렇게만 설정해도 되겠습니다. 로깅 설정만 거의 1/3로 줄어듭니다.

사용법은

1. SLF4J API를 이용해서 로거를 만들고..

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

Logger log = LoggerFactory.getLogger(AccountJsonBindingTests.class);

2. 다음과 같이 로깅하면 됩니다.

log.info(“name is {}”, name);

+를 사용해서 문자열 연산을 할 필요도 없고, if문을 줘서 문자열 연산을 막을 필요도 없습니다.

3. log4j 설정은 프로퍼티 파일이나 XML로 할 수 있는데 스프링 3.0 예제는 보통 XML을 사용하더군요. src와 test 소스 폴더 하위의 클래스패스 루트에 각각 다음과 같은 log4j.xml 파일을 둡니다.

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE log4j:configuration PUBLIC “-//LOGGER” “log4j.dtd”>

<log4j:configuration xmlns:log4j=”http://jakarta.apache.org/log4j/”>

    <!– Appenders –>
    <appender name=”console” class=”org.apache.log4j.ConsoleAppender”>
        <param name=”Target” value=”System.out” />
        <layout class=”org.apache.log4j.PatternLayout”>
            <param name=”ConversionPattern” value=”%-5p: %c – %m%n” />
        </layout>
    </appender>

    <!– 3rdparty Loggers –>
    <logger name=”org.springframework.core”>
        <level value=”info” />
    </logger>

    <logger name=”org.springframework.beans”>
        <level value=”info” />
    </logger>
   
    <logger name=”org.springframework.context”>
        <level value=”info” />
    </logger>

    <logger name=”org.springframework.web”>
        <level value=”info” />
    </logger>

    <!– Root Logger –>
    <root>
        <priority value=”warn” />
        <appender-ref ref=”console” />
    </root>
   
</log4j:configuration>

src와 test 간의 차이는 마지막 부분의 <root> 안의 <priority>가 src에서는 warn이고 test에서는 info라는 것 뿐이 없습니다. 이 설정에서는 Log4J를 사용하고 있는데.. logback API를 이용해서 설정해도 당근 잘 동작합니다.

스프링 프레임워크 3.0이 GA 됐다.

원문: http://www.springsource.org/node/2266
봄싹 위키: http://springsprout.org/wiki/1495.do

긴 여정을 거쳐, 드디어 스프링 3.0 GA (배포)를 이용할 수 있게 됐다는 것을 발표하게 되어 기쁘다! 스프링소스는 지금 축제 중이다. 여러분도 같이 파티에 참여하기 바란다. 🙂

가장 최근 소식으로, 스프링 3.0 GA는 이제 (지난주에 배표된 GlassFish v3과 같은) 자바 EE 6 파이널 런타임 환경과 호환가능하며 이미 (EcliseLink 2.0 같은) JPA 2.0 파이널을 지원하고 있다. 또한 (JSR-250 v1.1에) 새로 추가된 @ManagedBean 컴포넌트 스캐닝을 지원하며 애노테이션-주도 의존성 주입에 활용할 (JSR-330) @Inject와도 잘 동작한다.

여러분의 편의를 위해 스프링 3.0 전체 주요 기능을 요약했다.

* 스프링 EL(SpEL): 빈 정의에서 사용할 코어 표현식 파서로, 내부 빈 구조와 환경적인 데이터 구조 속성 값에  #{…} 문법을 사용하여 접근할 수 있다.

* 애노테이션-기반 컴포넌트 지원 확장: (스프링 JavaConfig로 알려져 있는)설정 클래스 개념과 애노테이션 팩토리 메서드를 도입했다. 스프링은 또한 환경 값을 @Value 표현식으로도 주입할 수 있게 해주며, 동적인 #{…} 표현식과 정적인 ${…} 대체공간(placeholder)을 이용하여 설정 구성(configruation settings)을 참조할 수 있게 해준다.

* 강력한 스테레오타입 모델: 메타 애노테이션을 사용한 ‘숏컷’ 애노테이션 생성을 지원한다. 예를 들어 기본 스코프와 기본 트랜잭션 특성을 가지고 있는 커스텀 스테레오타입을 만들 수 있다. @Service, @Scope(“request”), @Transactional(readOnly=true)를 모두 가지고 있는 @MyService 애노테이션 한개를 만들어 사용할 수 있다.

* 표준화된 의존성 주입 애노테이션: 스프링 3.0은 자바 애노테이션-기반 의존성 주입에 관한 JSR-330 스펙을 완전히 지원한다. @Inject와 관련된 qualifier와 providier 모델을 스프링 내부의 @Autowired에 대한 대체제로 지원한다.

* 제약 애노테이션 기반의 선언적인 모델 검증: JSR-303 빈 검증기(validation provider)에 대한 스프링-스타일 구성을 했다. 애노테이션을 이용한 검증 옵션을 스프링 MVC에서 이용할 수 있다. 스프링의 바인딩 결과 기능을 통해 제약사항 위반에 대한 일관적인 뷰를 제공한다.

* 강화된 바인딩과 애노테이션-기반 포매팅: 표준 PropertyEditor에 대한 대체제로 Converter와 Formatter SPI를 제공한다. 포맷팅은 JSR-303 제약과 비스한 스타일로 애노테이션을 이용할 수 있다. 예를 들어 @DateTimeFormat을 사용할 수 있다. 또한 새로운 mvc 네임스페이스를 사용하여 스프링 MVC에 포맷팅과 검증기를 편하게 설정할 수 있으니 확인해 보기 바란다.

* 방대한 REST 지원: REST스타일 요청 매핑, @PathVariable 매개변수를 사용한 URI 변수 추출, 컨텐츠 교섭(content negotiation)을 통한 뷰 판단과 같은 고유의 REST를 스프링 MVC에서 사용할 수 있다. 클라이언트쪽 REST 지원은 RestTemplate 클래스를 이용할 수 있다.

* 풍부한 고유 포틀릿 2.0 지원: 스프링 MVC는 포틀릿 2.0 환경과 포틀릿 2.0의 새로운 이벤트와 리소스 요청 모델을 지원한다. 일반적인 포틀릿 요청 특징에 따른 구체화된 매핑 기능을 제공한다. @ActionMapping, @RenderMapping, @ResourceMapping, @EventMapping.

* 객체/XML 매핑(OXM): 스프링 웹 서비스에 있었지만, 지금은 스프링 프레임워크 코어로 이동했다. JAXB2, Castor 등을 지원하는 마샬링 언마샬링 추상화를 제공한다. 스프링 MVC와 스프링 JMS에 XML 페이로드(payload) 연동 옵션을 제공한다.

* 차세대 스케줄링 기능: cron을 지원하는 TaskScheduler와 Trigger 매터니즘을 새로 추가했다. 스프링 3.0은 편리한 task 네임스페이스와 @Async, @Scheduled 애노테이션을 제공한다. 고유의 쓰레드 풀 또는 서버가 관리하는 쓰레드 풀에서 실행될 수 있다.

이러한 큰 테마들 이외에, 스프링 2.5에 업그레이드 할 때 특히 좋아할 수백개의 구체적인 개선 사항사항이 있으니 변경사항과 자바독을 확인하기 바란다.

시스템 요구사항에 따르면, 스프링 3.0은 다양한 환경을 다룬다. 두 가지 주요 특징으로, 스프링 3.0은 자바 SE 5 이상서블릿 2.4 이상을 지원한다. 예를 들어 톰캣 5.x와 6.x를 지원한다. 또한 웹스피어 6.1과 웹로직 9.2와 같은 유명한 엔터프라이스 서버와도 호환가능하다. GlassFish v3은 이미 지원하고 있다.

마무리 하자면, 스프링 3는 여러분의 서버를 업그레이할 필요 없이 완전히 새로운 컴포넌트 모델 기능과 JSR-330 주입과 JSR-303 검증같은 표준을 제품 환경에 가져다 준다! 여러분이 해야 할 일은 스프링을 사용중인 애플리케이션의 라이브러리를 스프링 3.0으로 바꾸는 것 뿐이다.

줄겨라 그리고 다음에 이어질 구체적은 스프링 3 기능에 대한 글과 스프링 3.0에서 돌아가는 예제들을 기대하기 바란다!

ps: 반가운 마음에 급하게 번역하느라.. 좀 날림입니다. 이해해 주세요;

[스프링 3.0] 스프링 bean과 일반 자바 객체가 호출하는 @Bean 메서드의 차이

public class JavaConfigTest {

    AnnotationConfigApplicationContext ac;

    @Before
    public void setUp(){
        ac = new AnnotationConfigApplicationContext(AppConfig.class);
        assertThat(ac, is(notNullValue()));
    }

    @Test
    public void getBean(){
        SampleBean bean1 = ac.getBean(“sampleBean”, SampleBean.class);
        SampleBean bean2 = ac.getBean(“sampleBean”, SampleBean.class);
        assertThat(bean1, is(notNullValue()));
        assertThat(bean2, is(notNullValue()));
        assertThat(bean1, is(bean2));

        AppConfig config1 = new AppConfig();
        SampleBean bean3 = config1.sampleBean();
        assertThat(bean3, is(not(bean2)));

        AppConfig config2 = ac.getBean(“appConfig”, AppConfig.class);
        SampleBean bean4 = config2.sampleBean();
        assertThat(bean4, is(bean2));
    }

}

스프링 3.0 애노테이션 기반 설정을 익히기 위해서 처음 만들어본 테스트입니다. 이 테스트에서 알 수 있는 건 바로 이 글의 제목에서처럼 @Bean이 붙어있는 메서드를 어떤 객체를 이용해서 호출하느냐에 따라 그 결과가 다를 수 있다는 겁니다.

@Configuration
public class AppConfig {

    @Bean
    public SampleBean sampleBean(){
        return new SampleBean();
    }
}

이건 설정한 빈이고 SampleBean은 뭐 암거나;; @_@;

결론은 new 로 만든 AppConfig와 스프링에서 가져온 AppConfig의 @Bean이 붙은 메서드가 반환해주는 값이다르다는 겁니다. 전자는 일반적인 Java 문맥대로 sampleBean()에서 new SampleBean()으로 새로운 객체를 만들어서 받은 것이고, 후자는 sampleBean() 메서드 호출을 가로채서 기존의 bean을 반환해준 겁니다.

이 경우는 매우 간단한 경우에 속합니다. 하나는 스프링이 관리하는 빈이었고, 하나는 일반 자바 객체였으니까요. 그런데 만약에 둘 다 스프링의 빈이라면? 그 중에 하나는 @Configuration, 다른 하나는 @Component라면?

@Component로 설정한 빈 내부에 위와 똑같은 설정이 들어있다면? 반환하는 객체의 값이 조금 다르나면??

빈 스캔은 어찌하나?

정말 복잡하군요;; 하나씩 차근 차근 해보겠습니다.

[스프링 3.0] RC2 릴리즈~

요즘 스프링에 관심이 슬슬 가시기 시작하네요. 벌써 3일이나 지나서야 RC2로 버전을 올리다니.. 예전 같았으면 공개되자마자 버전을 올렸을텐데 말이죠. 하긴.. 뭐 3일 정도 늦었지만, 그래도 봄싹은 아마도 한국에서 가장 빨리 스프링 최신 버전을 적용한 프로젝트가 될 것 같습니다. 후훗

중요 변경 사항을 살펴보겠습니다.

* updated to final versions of JSR-330 “javax.inject” and JSR-303 “javax.validation” APIs
* full compliance with the JSR-330 TCK (i.e. full compliance with the final specification)
* support for Hibernate Validator 4.0 GA (as the JSR-303 reference implementation)
* added support for load-time weaving in JBoss 5.x
* added support for recent EHCache 1.6 configuration properties to EHCacheFactoryBean
* added AnnotatedBeanDefinitionReader helper for programmatic registration of annotated classes
* added AnnotationConfig(Web)ApplicationContext for convenient registration/scanning of classes
* added GenericXmlApplicationContext with flexible configuration options for its XML support
* AbstractApplicationContext can also start up in case of system properties access failure
* internal MergedBeanDefinitionPostProcessors apply after all other post-processors
* inner beans detected as ApplicationListeners as well (only supported for inner singletons)
* child bean definition’s scope attribute can be inherited from parent bean definition now
* introduced SmartLifecycle interface with auto-startup and shutdown order support
* introduced LifecycleProcessor delegate, customizable through “lifecycleProcessor” bean
* MessageListenerContainers and Quartz SchedulerFactoryBean start up on refresh instead of init
* added initialize-database tag to jdbc namespace for populating external data sources with data
* PathMatchingResourcePatternResolver leniently ignores non-existing root directories
* DefaultConversionService understands “on”/”off”, “yes”/”no”, “1”/”0″ as boolean values
* CustomEditorConfigurer supports PropertyEditor instances again (with deprecation warning)
* revised MethodParameter’s annotation accessor methods
* ClassUtils is now parameterized with Class<?> and Class<T> where appropriate
* DataBinder now accepts var-args to set allowed, disallowed, and required fields
* DataBinder auto-grows nested paths on traversal (avoiding NullValueInNestedPathException)
* fixed enum binding regression with WebRequestDataBinder (as used by @MVC data binding now)
* fixed FieldError to expose rejected input value as String value instead of as array
* JSR-303 Validator will only register validation failures if no binding failure happened
* ContentNegotiatingViewResolver works with ignoreAcceptHeader and defaultContentType as well
* added Spring MVC namespace, with convenient mvc:annotation-driven configuration element
* default number and datetime formatters configured when using the Spring MVC namespace
* full support for datetime formatting using the Joda Time library (automatically enabled)
* added convenient @NumberFormat and @DateTimeFormat annotations for declarative formatting
* implicit T.valueOf(S) and constructor T(S) lookup if no explicit S->T converter matches
* AbstractExcelView is compatible with Apache POI 3.0 as well as 3.5 now
* TilesConfigurer only sets up EL support if JSP 2.1 is present (for JSP 2.0 compatibility)
* re-introduced Struts 1.x support (“org.springframework.web.struts”) in deprecated form
* deprecated scheduling support for JDK 1.3 Timer (“org.springframework.scheduling.timer”)
* deprecated remoting support for JAX-RPC (in favor of JAX-WS)

[스프링 3.0] @Valid 실습

1. 라이브러리 추가.

        <!– Validation –>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>com.springsource.org.hibernate.validator</artifactId>
            <version>4.0.0.GA</version>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>com.springsource.javax.xml.bind</artifactId>
            <version>2.1.7</version>
        </dependency>

2. 빈 설정.

    <bean
        class=”org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter”>
        <property name=”cacheSeconds” value=”0″ />
        <property name=”webBindingInitializer”>
            <bean class=”org.springframework.web.bind.support.ConfigurableWebBindingInitializer”>
                   <property name=”validator” ref=”validator” />
               </bean>
        </property>
    </bean>
   
    <bean id=”validator” class=”org.springframework.validation.beanvalidation.LocalValidatorFactoryBean”/>

3. 애노테이션 기반 검증 설정

    @Column(length = 100)
    @NotEmpty(message=”제목을 입력하세요!”)
    private String title;
    @Column(columnDefinition=”TEXT”)
    @NotEmpty(message=”제목을 입력하세요!”)
    private String contents;

4. 컨트롤러 코드 수정.

    @RequestMapping(value = “/notice/update/{id}”, method = RequestMethod.POST)
    public String updateForm(@Valid Notice notice, BindingResult result, SessionStatus status) {
        if (result.hasErrors()) {
            return “notice/update”;
        } else {
            noticeService.update(notice);
            status.setComplete();
            return “redirect:/notice/” + notice.getId() + “.do”;
        }
    }

끝~!! 기본 에러 메시지는 애노테이션에서 변경할 수 있습니다.

이제 JSR 303 애노테이션과 그 확장 애노테이션에 뭣들이 있는지 살펴봐야겠네요.