달력

5

« 2024/5 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

이 글은 하얀말님의 2009년 3월 26일의 미투데이 내용입니다.

:
Posted by 하얀 말

이 글은 하얀말님의 2009년 3월 20일의 미투데이 내용입니다.

:
Posted by 하얀 말

왜 Apache HTTP Server와 Tomcat을 연동하는가?

Apache Tomcat(이하 Tomcat)은 아마도 가장 널리 알려진 JSP / Servlet Engine일 것입니다. JSP / Servlet 명세에 대한 참조 구현물(Referencial Implementation, 흔히 줄여서 RI라고도 하죠) 역할도 하고 있으며, 실 업무에서도 꽤 씁니다(왕년에 Naver Blog를 쓸 때 한번은 Java Exception Trace log가 Web Browser에 표시된 것을 본 적이 있었습니다. 그 덕에 Naver Blog가 Tomcat을 쓴다는 것을 알았죠).

 

그러나 실전에서는 web server와 tomcat 같은 JSP/Servlet Engine 둘을 연동해서 쓰지, tomcat만 쓰지는 않습니다. 그 이유는 아래와 같습니다.

성능 상의 이유

JSP/Servlet Engine 상에서 동작하는 Servlet이나 JSP라는, (동일한 HTTP Request를 보내도 매 번 그 결과가 다를 수 있는) 동적인 HTTP Response를 생성해 보내는 것들입니다. 그에 비해 단순한 HTML 문서, image, CSS(Cascading Style Sheet), Javascript file은 거의 변할 일는 (동일한 HTTP Request를 보내면 그 결과가 늘 같은) 정적 contents입니다. 이런 정적 contents는 통상적으로 Web Server가 JSP/Servlet Engine보다 더 빠르게 service합니다.

 

감이 오시나요? 결국 정적 content는 정적 contents 처리에 강한 Web Server가 처리하고, 동적 contents는 JSP/Servlet Engine이 맡는 것입니다. 일단 HTTP Request를 Web Server가 먼저 받아보고 정적 contents를 요구하면 자신이 처리하고, 동적 contents request라면 이 request를 JSP/Servlet Engine에게 넘기죠. 아니면 특정 URL pattern이 들어오면 JSP/Servlet Engine으로 넘기는 방법도 있습니다. 결국 이렇게 하면 부수적으로 동적 contents 생성하느라 바쁜 JSP/Servlet Engine에 부하를 덜 줄 수 있고 정적 contents service하느라 귀중한 JVM Heap을 아낄 수 있는 이점도 누릴 수 있습니다.

보안 상의 이유

보통 JSP/Servlet Engine은 중요한 업무 절차에 대한 구현을 가지고 있게 마련입니다. 단순한 image, CSS 같은 정적 contents를 담은 Web Server보다 더 안전해야 보호해야 한다는 뜻이 됩니다. 보통 어떤 기업 같은 조직의 network를 구성할 경우 외부 network와 조직의 network를 방화벽(firewall)으로 단절시키고 방화벽에 규칙(rule)을 등록, IP packet이 제한적으로만 그 방화벽을 넘다들 수 있도록 합니다. 안전성이 더 높아야 하는 server들이 있는 network zone는 여기에 한 번 더 방화벽을 칩니다. 그리고 이 두 방화벽 사이의 network zone을 DMZ라고 합니다.

 

이렇게 Web Server와 JSP/Servlet Engine을 따로따로 쓰면 DMZ에 덜 중요한 data를 가진 web server를 놓고 이중 방화벽 뒤에 있는 network zone에 JSP/Servlet Engine을 놓음으로써 높은 보안성을 획득하면서도 외부에 동적 contents를 제공할 수 있게 됩니다.

가용성 상의 이유

web server도 하나, JSP/Servlet Engine도 하나라면 둘 중 하나만 죽으면 정상적인 service가 불가능합니다. 따라서 절대 멈추면 안되는 service(세계화가 되면서 이런 요구 사항은 더 늘었습니다. 지구 상 어딘가는 늘 업무 시간이니까요)를 담당하는 web server, JSP/Servlet Engine은 두 개 이상을 가동하는 이중화를 적용합니다.

 

web server가 어떤 HTTP Request를 받아 이를 JSP/Servlet Engine으로 넘기려 할 때 그 JSP/Servlet Engine이 이중화가 되어 있다면 web server는 이 request를 좀 한가한 JSP/Servlet Engine에 넘긴다던지 할 수 있습니다(물론 실제로는 간단하게는 round robin부터 시작해서 이에 대한 여러가지 방법이 있습니다). 내지는 JSP/Servlet Engine 중 하나가 비정상적으로 종료한 상태이면 현재 살아 있는 JSP/Servlet Engine에게 이 request 처리를 위임, 전반적인 service 중단을 막을 수 있습니다.

 

준비물

  • Apache Tomcat

    • Apache Tomcat : Apache Tomcat 대표 site. Tomcat을 내려받으려면 가야 하는 곳.
  • Apache HTTP Server

    • Apache HTTP Server : Apache HTTP Server 대표 site.
    • Apache Lounge : Windows용 Apache HTTP Server 정보가 풍부함. Windows용 Apache HTTP Server는 여기에서 받을 것을 추천!
  • mod_jk

    • Apache Tomcat : Apache Tomcat 대표 site. mod_jk도 여기서 받을 수 있습니다(이 site에서는 mod_jk를 'Apache Connector'라고 부릅니다).

 

작업 절차

 

간단한 구성

간단한 구성이란, 개발이나 가벼운 Web Service 운영을 목적으로 하나의 Apache HTTP Server + 하나의 Tomcat 연동 구성을 하는 것입니다. 이 작업에 대한 구체적 작업 절차는 [tomcat]apache, tomcat 연동하기 글에서 잘 설명하고 있습니다(Windows / Linux에서 mod_jk로 Apache와 Tomcat 연동하는 것을 proxy_module과 같이 설치할 경우와 아닌 경우 모두 설명하고 있습니다).

 

고가용성을 위한 구성

Naver Blog와 같이 사용자가 많다거나 장애 등을 감내할 수 있는(Fault Tolerant) Web Service를 구성하려면 위 간단한 구성으로는 어렵고 여러 개의 Apache HTTP Server + 여러 개의 Tomcat 연동 구성을 해야 합니다. 이렇게 해야 일부 Apache HTTP Server나 Tomcat이 죽어도 나머지들이 request를 처리할 수 있지요. 이러한 특성을 고가용성(High Availability)이라 하는데 이 고가용성은 위와 같은 단순한 설정만으로는 얻기 어렵습니다. 이런 고가용성 설정은 '아파치와 톰캣을 활용한 대용량 웹서비스 운영'이란 글에서 잘 설명하고 있습니다.

 

참고 문헌

 

예시

  • Apache HTTPD 2.2 설정 file : mod_jk로 Apache HTTP Server 2.2와 Tomcat 6을 연동시킨 결과로 나온 Apache Web Server 2.2 설정 file.
  • Apache Tomcat 6 설정 file : mod_jk로 Apache HTTP Server 2.2와 Tomcat 6을 연동시킨 결과로 나온 Apache Tomcat 6 설정 file.
  • mod_jk.conf : 실제 mod_jk 설정 정보를 담은 mod_jk 설정 file.

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

:
Posted by 하얀 말

이 글은 하얀말님의 2009년 3월 14일의 미투데이 내용입니다.

:
Posted by 하얀 말

이 글은 하얀말님의 2009년 3월 9일의 미투데이 내용입니다.

:
Posted by 하얀 말
XP에서의 Windows Live Messanger 한글 입력 오류 때문에 짜증나셨죠? Windows Live Messanger 2009 version을 쓰는 저도 무지하게 짜증났었는데요, 링블로그의 라이브 메신저 한글 입력 오류 해결 팁이란 글에 sisters라는 분이 단 덧글에 나오는 해결책을 적용, 정상적으로 쓰고 있습니다.

sisters님 글이 덧글이다 보니 너무 축약적이라, 다른 분들에게도 도움이 될까 해서, 좀 더 자세히, 스샷 첨부해서 글 올려봅니다(그래도 열라 간단합니다). 링블로그 주인장 말씀처럼, 해결책 중 최강입니다. 알려준 sisters님 감사!!!!
Windows Live Messanger 설치 directory에서 Windows Live Messanger 실행 파일을 오른쪽 click하여 속성 대화 상자를 띄웁니다.

 
위 그림처럼 호환성 tab에서 '이 프로그램에 대해 '고급 텍스트 서비스 사용 안 함' 선택하고 '확인' 단추 누르면 끝!(이 놈이 핵심)

물론 Windows Live Messanger 재기동은 해 주셔야겠죠?

'고급 텍스트 서비스'라는 녀석의 정체는 다음 글들을 살펴봐 주십시오.


(덧)
computer 쓰면서 한글 때문에 골머리 그만 썩었으면 좋겠습니다... 역시 이런 문제는 외국 애들은 한계가 있겠죠? 이래저래 IT 역량을 높여야 할 노릇입니다.


:
Posted by 하얀 말

이 글은 하얀말님의 2009년 2월 28일의 미투데이 내용입니다.

:
Posted by 하얀 말

(역자 주)

본 글은 Springsource 사의 Mark Fisher가 2009년 2월 13일에 영어로 쓴 Spring Integration in 10 minutes을 우리말로 번역한 것입니다.


10분만에 Spring Integration 따라잡기

두 달 전 SpringOne America에서 Spring Integration 1.0 GA release를 발표했고, 그 때부터 얼른 "바로 시작하기" blog post를 쓰려 했습니다. 글쎄요, 새해부터는 늘 바쁜 나머지, 일단 10단계의 따라하기 예제 제공을 목표로 했습니다. 각 단계는 대략 1분 정도가 걸립니다... 생각하느라 멈추지만 않으면요. ^^ 어쨌든, 더 꾸물거리지 말고, 바로 가 보죠!

1단계: Spring Integration 배포본 내려받기

여기에서 가장 최신의 배포판을 얻을 수 있습니다.
http://www.springsource.com/download/community?project=Spring%20Integration

내려받기가 끝나면, zip file을 푸세요. Spring Integration project를 이루는 JAR들을 담은 'dist' directory가 있을 것입니다. 또한 'lib' directory에는 Spring Integration이 필요로 하는 외부 library들이 있습니다.

2단계: project 생성

이 예제에서 Eclipse를 쓰지만, 이 작업은 당연히 다른 IDE에서도 가능합니다. Maven이나 Ivy도 쓸 수 있지만, 이 예제는 매우 간단해서, directory를 만들고 JAR file들을 추가하는 것으로 충분합니다.

새 'Java Project'를 생성하고('Package Explorer' view에서 오른쪽 click 후 'New -> Java Project'), 그 project 안에 'lib' directory를 만듭니다. 그리고나서 다음 JAR file들을 Spring Integration의 'dist'와 'lib' directory에서 이 project의 'lib'으로 옮깁니다.

dist에서는

  • org.springframework.integration-1.0.1.RELEASE.jar
  • org.springframework.integration-file-1.0.1.RELEASE.jar

lib에서는

  • com.springsource.org.aopalliance-1.0.0.jar
  • com.springsource.org.apache.commons.logging-1.1.1.jar
  • org.springframework.aop-2.5.6.A.jar
  • org.springframework.beans-2.5.6.A.jar
  • org.springframework.context-2.5.6.A.jar
  • org.springframework.core-2.5.6.A.jar
  • org.springframework.transaction-2.5.6.A.jar

'lib' directory를 refresh(F5를 치세요)한 다음 build-path에 위 JAR file들을 추가하십시오(JAR file들을 고른 다음, 오른쪽 click 후 "Build Path -> Add to Build Path" 선택). 마지막으로, 'src' directory에 'blog' package를 추가하시고요.

3단계: Spring Integration 시작

Spring IDE나 SpringSource Tool Suite을 쓰신다면, Spring project의 특성을 자연스럽게 쓸 수 있으므로 그냥 새 bean 정의 file을 생성하려면 'blog' package를 오른쪽 click만 하면 됩니다. 그렇지 않더라도 아래 내용을 생성하고 file 이름을 'config.xml'로 하시기만 하면 됩니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:si="http://www.springframework.org/schema/integration"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd
           http://www.springframework.org/schema/integration
           http://www.springframework.org/schema/integration/spring-integration-1.0.xsd"
>
</beans>

element 한 개를 더 추가하겠습니다. 이는 Java in-memory queue를 근간으로 하는, 한 번에 10개의 message를 담을 수 있는 Message channel을 정의합니다.

<si:channel id="channel">
    <si:queue capacity="10"/>
</si:channel>

4단계: Bootstrap Java class 정의

Spring Integration component들은 Spring ApplicationContext에 들어있습니다. 그래서 설정 file로 ApplicationContext 하나를 만드는 일만 하면 됩니다. Web Application에서 구동하려면 Spring의 ContextLoaderListener으로 기동할 수 있고, 또는 만약 dmServer에서라면, 저절로 알아서 기동할 겁니다. 이 초간단 예제에서는 그냥 ('blog' package에 있는) Bootstrap이라는 class에 main() method를 만드는 것으로 하겠습니다.

public class Bootstrap {
    public static void main(String[] args) {
        new ClassPathXmlApplicationContext("blog/config.xml");
    }
}

(언제든지 Eclipse에서 Ctrl+Shift+O…, Mac에서는 Command+Shift+O를 눌러 "organize imports"를 할 수 있습니다).

5단계: Spring Integration Message 송/수신

이제, context에세 channel을 가져와 message를 보낼 수 있습니다. 아직 구독자(subscriber)가 없기 때문에(다음 단계에서 할 것입니다), 같은 channel에서 message를 받기로 하겠습니다. 이를 통해 설정이 제대로 되었는지 확인할 수 있죠. 아래처럼 main() method를 고치세요.

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    PollableChannel channel = (PollableChannel) context.getBean("channel");
    channel.send(new StringMessage("Spring Integration이 끝내줘요"));
    Message<?> reply = channel.receive();
    System.out.println("received: " + reply);
}

이걸 돌리면 message 객체의 toString() method 수행 결과가 console에 찍히는 것을 보실 수 있습니다.

6단계: Service 생성

Spring Integration은 program들이 Spring과 느슨한 결합도를 가지는 것을 추구합니다. 즉, 우린 이 예제를 점진적으로 고쳐서 어떤 code도 framework에 엮여버리지 않도록 할 것입니다. 첫번째 할 일은,  message를 구독할 POJO Service를 추가하는 것입니다. 이 예제에서는 단순히 문자열을 대문자로 바꾼 뒤 느낌표를 덧붙이는 일을 합니다.

public class Shouter {
    public String shout(String s) {
        return s.toUpperCase().concat("!!!");
    }
}

7단계: Spring 설정에 Service 추가

이 Service는 그냥 일반적인 bean으로 추가하면 됩니다.

<bean id="shouter" class="blog.Shouter"/>

그 다음, 우린 Service bean에 입/출력 channel을 붙이는 "Service Activator"를 추가할 것입니다. 현재 있는 "channel"의 이름을 "output"으로 바꾸고, 입력용으로 단순한 non-buffering channel을 더합니다. 전체 설정은 아래와 같습니다.

<si:channel id="input"/>
<si:channel id="output">
    <si:queue capacity="10"/>
</si:channel>
<si:service-activator input-channel="input"
           output-channel="output"
           ref="shouter"
           method="shout"/>
<bean id="shouter" class="blog.Shouter"/>

단계 8: Message를 보내 Service 호출

input channel에 message를 보내고 output channel에서 message를 받도록 main() method를 고칩니다. 의존성을 lookup하는 부분과 channel 객체에 대한 type casting이 바뀌었음을 주목하세요(지금부터 output은 PollableChannel이고 'input' channel은 output과 달리 non-buffering channel입니다).

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    MessageChannel input = (MessageChannel) context.getBean("input");
    PollableChannel output = (PollableChannel) context.getBean("output");
    input.send(new StringMessage("Spring Integration이 끝내줘요"));
    Message<?> reply = output.receive();
    System.out.println("received: " + reply);
}

9단계: 출력을 file로 보내기

Channel Adapter를 추가하면 main() method에서 출력을 polling하지 않고 결과를 곧장 file에 보낼 수 있습니다. 이렇게 하면 polling이 필요 없으므로, 먼저 output channel의 하위 element인 queue를 없애겠습니다.

<si:channel id="output"/>

Channel Adapter를 더합니다. 현재 directory를 지정할 수도 있고, Windows라는 drive 문자를 포함할 수도 있습니다(예를 들면 "C:/tmp" 같은).

<file:outbound-channel-adapter channel="output" directory="/tmp"/>


그 다음, Bootstrap의 main() method를 송신만 하도록 고칩니다.

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    MessageChannel input = (MessageChannel) context.getBean("input");
    input.send(new StringMessage("Spring Integration이 끝내줘요"));
}

XSD 설정에 'file' namespace를 추가하는 일도 해야 합니다. 최상위의 'beans' element가 아래처럼 생길 것입니다.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:si="http://www.springframework.org/schema/integration"
       xmlns:file="http://www.springframework.org/schema/integration/file"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans.xsd
            http://www.springframework.org/schema/integration
            http://www.springframework.org/schema/integration/spring-integration-1.0.xsd
            http://www.springframework.org/schema/integration/file
            http://www.springframework.org/schema/integration/file/spring-integration-file-1.0.xsd">

예제를 돌리면 ".msg" 확장자가 달린 file에 결과를 볼 수 있습니다(file 이름 생성 규칙도 추가할 수 있지만 이 post의 범위를 벗어납니다).

10단계: Gateway interface 생성

마지막 단계의 목표는 Spring과의 의존성을 완벽하게 없애는 것입니다. Message를 Message Channel에 보내기보다는, 단순한 interface의 인자로 문자열를 보내는 것이 훨씬 더 깔끔합니다. 'blog' package에 다음 interface를 추가합니다.

public interface Gateway {
    void send(String s);
}

그리고, 다음 element를 설정에 추가합니다.

<si:gateway id="gateway" service-interface="blog.Gateway" default-request-channel="input"/>


마지막으로, main() method에서 channel 대신 Gateway를 씁니다. 이제 단순히 문자열만 넘기면 됩니다.

public static void main(String[] args) {
    ApplicationContext context = new ClassPathXmlApplicationContext("blog/config.xml");
    Gateway gateway = (Gateway) context.getBean("gateway");
    gateway.send("Spring Integration이 끝내줘요");
}

마치며

이 글이 Spring Integration에 대한 쓸만한 소개글이었으면 좋겠습니다. 여지껏 다룬 내용의 주안점은 Spring과 낮은 결합도를 가지면서도 통합 계층을 쉽게 만들 수 있다는 점입니다. 만약 독자 제위께서 여러 endpoint를 추가하기 시작한다면 이에 대한 가치를 피부로 느끼실 수 있을 것입니다. 하다 보면 filter, transformer, router를 더 추가해야 할 지도 모르겠습니다.

Spring Integration에는 이 예제에서 나온 것보다 훨씬 더 풍부한 기능이 있습니다. 더 살펴보시려면, 'org.springframework.integration.samples' module(배포본의 'src' directory에 source도 들어있습니다)에 들어있는 다양한 project들을 검토해 보시고 참조 문서를 읽어보십시오. 물론, Spring Integration home page에서도 풍부한 정보를 찾을 수 있습니다.

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

:
Posted by 하얀 말

이 글은 하얀말님의 2009년 2월 27일의 미투데이 내용입니다.

:
Posted by 하얀 말

*** Juergen Hoeller가 Spring Framework Team Blog에 올린 글을 번역한 것입니다.

Spring 3.0 milestone을 사용이 가능함을 발표할 수 있어 기쁩니다(내려받는 page).

이번 release에는 다음과 같은 다양한 개선 사항과 신기능이 들어있습니다.

API를 Java 5 형태에 맞도록 수정: 일관되게 generic collection과 map을 썼고, 일관되게 generic을 적용한 FactoryBean을 썼으며, Spring AOP API에서는 bridge method을 일관되게 결정하도록 했습니다. Generic을 적용한 ApplicationListener들은 자동으로 정해진 type에 해당하는 event만 받습니다. TransactionCallback와 HibernateCallbackcallback 따위의 모든 Callback interface는 이제 generic을 적용한 결과값을 돌려주도록 선언했습니다. 전반적으로, Spring core codebase는 이제 산뜻하게 정리되어 Java 5에 잘 들어맞습니다.

동시성 지원 확대: 그동안 우리는 Spring의 TaskExecutor를 Java 5의 java.util.concurrent 기능과 밀접하게 통합시켜 왔습니다. 이제 ExecutorService adapter, ThreadFactory 통합 등과 아울러 Callable과 Future를 최우선적으로 지원합니다. 이들은 그간 최대한 JSR-236(Java EE 6용 Concurrency Utility)과 발맞추어 왔습니다. 더불어, @Async annotation(이나 EJB 3.1의 @Asynchronous annotation)을 써서 비동기적으로 method를 호출할 수 있습니다. 그리고 Spring 3.0 M3에는 scheduling을 편하게 설정할 수 있는, cron 형태의 timer 지원을 포함하는, scheduling namespace를 추가할 예정입니다.

OXM을 core에 포함: 객체(Object)/XML mapping module을 Spring Web Service project에서 Spring core project로 옮겼습니다. OXM을 Java 5에 걸맞게 수정해 왔으며, JAXB2, JiBX, Castor, XMLBeans, XStream을 쓰는 marshalling 및 unmarshalling을 지원합니다. 또한 Spring JMS(MarshallingMessageConverter)와 Spring MVC(MarshallingView)용 OXM 지원 기능도 있습니다.

RestTemplate: 새로운 client측 REST 지원 기능이 생겼습니다. 바로 오랫동안 기다려온, Spring solution으로부터 기대할 수 있는 유연하고 확장성이 풍부한 HTTP 처리 하부 구조를 지닌 RestTemplate입니다. 또한 Spring MVC에서의 REST 지원과 관련하여 몇몇 개선이 이루어졌습니다. Arjen이 올릴 최신 REST 지원 기능에 대한 blog post를 기대하세요!

Portlet 2.0 상의 MVC: 이제 Spring Portlet MVC는 Portlet 2.0 API(JSR-286)을 기반으로 합니다. (Portlet 2.0에서 정의하는) action 이름, window 상태, resource id, event 이름의 특성을 지원하는 기능을 포함한 Portlet MVC Handler method용 @ActionMapping, @RenderMapping, @ResourceMapping and @EventMapping annotations를 제공합니다.

신속한 JPA 2.0 지원: 마지막으로, 우리는 곧 나올 JPA 2.0 preview를 지원하는 JPA provider와 아울러 JPA 2.0 명세도 능동적으로 쫒아가고 있습니다. Spring 3.0 M2는 이미, Spring이 관장하는 transaction 하에서의 query timeout 및 Spring이 관리하는 EntityManager proxy에서의 QueryBuilder 접근 따위 같이, JPA 2.0 API를 지원합니다. JPA 2.0이 안정화되는대로 이 기능을 Spring 3.0 RC1에서 매듭짓겠습니다.

지금이야말로 Spring 3.0을 일찍 시도해 보기 좋은 때입니다! 여러분께서 어떻게 이를 쓰고 있는지 알려주세요... M2에는 아직 참조 문서가 없지만 더 자세해진 javadoc과 test suite이 있습니다. 앞으로 blog에도 예제들을 올릴 것이고요.

우린 이미 마지막 mileston 작업을 하는 중입니다. M3에서는 annotation 기반 factory method, (JSR-303 "bean validation"을 기초로 하는) 선언적 validation, 새 XML 설정 namespace(orm, scheduling)를 선보일 예정입니다. Spring MVC는 conversation 관리 관점에서 정밀 검토를 할 것이고요. 우리는 또한 필요해지는대로 JSP 2.0이 Spring과 매끄럽게 연동되도록 준비 중입니다.

참고 문헌

:
Posted by 하얀 말