달력

3

« 2024/3 »

  • 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

'스프링 프레임워크'에 해당되는 글 5

  1. 2012.04.29 Spring Framework 3.0 MVC(1)
  2. 2009.09.26 Spring 3.0.0 Release Candidate 1 Released
  3. 2009.05.04 Spring의 Roo Alpha 2에 대하여...
  4. 2008.12.07 SpringFramework 3.0 Released (3.0.0.M1)
2012. 4. 29. 15:12

Spring Framework 3.0 MVC(1) 공부하는 것/Spring Framework2012. 4. 29. 15:12

스프링 프레임크를 사용하기 시작한지는, 만 5년 정도 된것 같다. 아니 정확하게 이야기하면 알기 시작한지 5년이다. 그 동안 몇개의 프로젝트에는 적극적으로 사용해왔고, 사용하려고 했었다.

솔루션을 위한 내부의 기반 프레임워크를 개발하기에도, 그 자체만으로도 스프링은 너무 훌륭하기 때문에, Application의 공통 부분을 위한 기능들만을 최적화하고, 정의하는 것 만으로도 노력대비 좋은 결과들을 낼수 있었다. 다 로드존슨 아저씨가 많은 시간을 들여서 갈고 닦고, 발전시킨 노력의 결과들이다.

시간이 흐를수록 큰 조직에서는 코드와 PC와 씨름하기 보다는 수 많은 회의와 씨름을 하는 일이 많아진다. 더군다나 같이 협업하는 사람들이 많아지면, 본인이 원치 않아도 관리자의 길에서 뛰고 있는 모습을 보게된다. 딱 지금의 나의 모습니다.

공부하지 않고, 적절하게 판단하고 선택하고 방향에 대해서 이야기 할 수 있을까?
많은 고민을 하지만, 역시 시간이 절대적으로 부족하다.

요즘은 코드를 보기가 힘들정도로, 공부할 여유가 별로없다.
하지만, 사둔 책이 아깝다는 이유이든, 공부의 재미를 알았다는 이유이든 개발자로 살아가는 한은
꾸준히 배워야한다.

스프링 3.1은 또 다른 변호들을 이야기 할지는 모르겠다. 이전에 책을 보면서 정리한 내용인데 일단 올려놓는다.

[Spring Framework 3.0 - MVC]

·         스프링은 DespatcherServlet 7개의 Strategy를 기반한 MVC 프레임워크를 제공한다.

·         이중 DespatcherServlet는 가장 기본적이면서도 SpringMVC의 필수적인 기본 Servlet 역할과 스프링의 특징중의 하나인 Light-weight 컨테이너의 역할을 수행한다.

 

1.     @RequestMapping 핸들러 매핑

o    @MVC는 메소드 레벨에서 컨트롤러를 작성할 수 있다.

o    Annotation은 타입(클래스, 인터페이스)레벨뿐 아니라 메소드 레벨에도 적용 가능함.

o    @MVC 핸들러 매핑을 위해서는 DefaultAnnotationHandlerMapping이 필요하다.

o    DefaultAnnotationHandlerMapping은 기본 핸들러 이므로 다른 Handler Mapping bean이 명시적으로 등록이 되지 않았다면, 기본으로 사용이 가능하다.

o    만약, 다른 핸들러 매핑 빈이 등록이 되었다면, DefaultAnnotationHandlerMapping
명시적으로 등록을 해주어야 사용이 가능하다.

2.     Class/Method 결합 Mapping 정보

o    DefaultAnnotationHandlerMapping

·         @RequestMapping 애노테이션을 활용해서 타입레벨과 메소드 레벨 지원하며
타입레벨을 기본으로 삼고, 메소드 레벨의 어노테이션 정보는 타입레벨의 매핑을 세분화 하는데 사용한다.

o    @RequestMapping Annotation

·         Spring[] value(): URL 패턴

1.     String 배열 타입으로 URL 패턴을 지정해서 사용

2.     URL 패턴은 ANT 스타일과 와일드카드를 사용이 가능하다.

·         @RequestMapping("/hellow")

·         @RequestMapping("/admin/**/user")

·         @RequestMapping("/hellow", "/hi")

3.     "{ }"를 사용할때는, "{ }"의 위치에 해당하는 내용을 컨트롤러 Method에서 파라메터로 전달받을 수 있다. "{ }"에 들어가는 변수를 "path variable"이라고 부른다.

·         @RequestMapping("/user/{userid}")

·         RequestMethoe{} method(): HTTP Request Method

1.     Request Method GET, HEAD, POST, PUT, DELET, OPTIONS, TRACE 7개의 HTTP 메소드가 정의되어 있다

2.     HTTP 메소드를 추가하면 요청 메소드에 따라 다른 메소드를 매핑해 줄 수 있다.

·         @RequestMapping(value="/user/add", method=RequestMethod.GET)

3.     정의된 메소드 이외의 사용시 "HTTP 405 - Method Not Allowed"를 받음.

4.     타입레벨에서 URL을 주고 HTTP 요청 메소드를 지정할 경우 URL 생략가능.

·         @RequestMapping(method=RequestMethod.GET)

·         String[] params(): Request Parameter

1.     이것은 요청 Parameter와 그 값을 비교해서 매핑해 주는 것이다.

2.     같은 URL을 사용하지만, Parameter값에 따라 다른 작업을 할 때 사용한다.

·         @RequestMapping(value="/user/edit", params="type=admin")

3.     특정 Parameter 값이 존재하지 않아야 한다는 조건을 둘 경우 사용

·         @RequestMapping(value="/user/edit", params="!type")

·         String[] header(): HTTP 헤더

1.     Header 정보에 따라 매핑이 가능하다.

·         @RequestMapping(value="/view", headers = "content-type="text/*")

 

o    Type level 매핑과 Method level 매핑의 결합

·   타입(클래스오 인터페이스)레벨에 붙는 @RequestMapping은 타입내의 모든 매핑용 메소드의 공통 조건을 지정할대 사용한다.

·   메소드 레벨의 매핑은 클래스 레벨의 매핑을 상속한다.

      1. 컨트롤러가 각각 /user/add, /user/edit, /user/delete URL에 매핑

@RequestMapping("/user")

public class UserController{

@RequestMapping("/add") public String add(){ }

@RequestMapping("/edit") public String edit(){ }

@RequestMapping("/delete") public String delete(){ }

}

2.     타입 레벨의 URL패턴에 * **를 사용하여 매핑 가능

·         /user/*

·         /user/**  

·         타입레벨에서 공통의 매핑을 정의하고, 메소드 별로 세분화 해서 사용

 

o    Method 레벨 단독 매핑

·   공통 매핑 조건이 없을 경우, 조건을 주지 않고 메소드 레벨에 정의해서 사용.

·   이렇게 정의하지 않는다면, 클래스 자체가 매핑이 되지 않는다.

·   만약, @Controller 애노테이션을 붙여서 자동 빈 스캔을 사용할 경우는, 클래스 레벨의 @RequestMapping을 생략할 수 있다.

o    Type 레밸 단독 매핑

·   클래스 레벨의 URL 패턴이 /*로 끝나는 경우, apthem 레벨의 URL 패턴으로 메소드 이름을 사용할 수 있음.

·   아래는 /user/add /user/edit 로 각각 매핑

@RequestMapping("/user/*")

Public class UserController {

@RequestMapping public String add( ) { }

@RequestMapping public String edit( ) { }

}

 

 

 

 

 

:
Posted by 행복상자
기다렸던 사람들이 많았을 것 같다. 이제야, 오늘에야 Spring 3.0.0 RC1이 나왔으니까 말이다. 물론 Toby(일민)이를 비롯한 몇몇 선행적인 개발자들이 이미 열심히 공부하고 있고, 이의 전달도 열심인 것에 비하면, 최근에 나는 크게 관심을 두려고 노력하지 않았다. 개인적으로는 다른 사업부로 옮겨와서, 새로운 일을 맡아서 관심이 적어진(?) 것도 있지만, 사실은 그것 보다도, 기존에 내가 만든 Framework는 스프링 2.5.5 또는 2.5.6을 기반으로 설계되어 있다. 그리고 이것을 이용하여 여러 솔루션들이 개발되고 있는 중이어서, 자체 개발한 Framework의 Minor 체인지가 아닌 Big 체인지를 결정하기 쉽지 않기 때문이다. 만약 그것을 결정해야 한다고 해도 2년 후가 될 것이다. (상품으로 그리고 서비스를 하고 있는 시스템을 변경하기란 많은 결정해야할 문제에 직면해야 하는 용기가 필요한다. 그러나 이것은 모험이 아니다.)

현재 Springframework에서 제공하고 있는 메이져 Branch는 2가지이지만 앞으로는 3가지가 될 것이다.
Springframework 1.2 와 2.5 그리고 향후 주축이될 3.0이다.
그리고 이제는 3.0 Release Candidate 1이 나왔다. 이제는 또 열심히 공부할 시점이 된 것이다.
여러가지 변경된 API라이브러리들도 있고, 추가된 라이브러리들이 있는데, 이중에서 가장 먼저 눈에 들어왔던 것은 Jackson JSON라이브러리이다. 이른 아침에 Jackson 투터리얼을 보면서 시간 가는줄 몰랐다.
앞으로 정식 버전이 나올날이 멀지 않았지만, 언제가 될지는 잘 모르겠다. 올해 안에는 나오지 않을지...

Springframework 3.0 RC1의 변경 사항은 다음의 링크를 보면된다.

그리고, 아래는 이번에 RC1에 추가된 내용이다.

Changes in version 3.0.0.RC1 (2009-09-25)
-----------------------------------------

* upgraded to CGLIB 2.2, AspectJ 1.6.5, Groovy 1.6.3, EHCache 1.6.2, JUnit 4.7, TestNG 5.10
* introduced early support for JSR-330 "javax.inject" annotations (for autowiring)
* introduced early support for JSR-303 Bean Validation (setup and MVC integration)
* added default editors for "java.util.Currency" and "java.util.TimeZone"
* refined PathMatchingResourcePatternResolver's treatment of non-readable directories
* PathMatchingResourcePatternResolver understands VFS resources (i.e. works on JBoss 5.x)
* revised AccessControlContext access from BeanFactory
* AbstractBeanDefinitionParser can deal with null return value as well
* PropertyOverrideConfigurer's "ignoreInvalidKeys" ignores invalid property names as well
* PropertyPlaceholderConfigurer supports "${myKey:myDefaultValue}" defaulting syntax
* BeanFactory's default type conversion falls back to String constructor on target type
* BeanFactory tries to create unknown collection implementation types via default constructor
* BeanFactory supports ObjectFactory as a dependency type for @Autowired and @Value
* BeanFactory supports JSR-330 Provider interface as a dependency type for @Inject
* BeanFactory prefers local primary bean to primary bean in parent factory
* protected @Autowired method can be overridden with non-annotated method to suppress injection
* private @Autowired methods with same signature will be called individually across a hierarchy
* @PostConstruct processed top-down (base class first); @PreDestroy bottom-up (subclass first)
* ConfigurationClassPostProcessor detect @Bean methods on registered plain bean classes as well
* support for default "conversionService" bean in an ApplicationContext
* MBeanServerFactoryBean returns JDK 1.5 platform MBeanServer for agent id "" (empty String)
* changed NamedParameter/SimpleJdbcOperations parameter signatures to accept any Map value type
* refined logging in JMS SingleConnectionFactory and DefaultMessageListenerContainer
* introduced "ui.format" package as an alternative to PropertyEditors for data binding
* @RequestMapping annotation now supported for annotated interfaces (and JDK proxies) as well
* @RequestParam and co support placeholders and expressions in their defaultValue attributes
* @Value expressions supported as MVC handler method arguments as well (against request scope)
* JSR-303 support for validation of @MVC handler method arguments driven by @Valid annotations
* refined response handling for @ExceptionHandler methods
* @ResponseStatus usage in handler methods detected by RedirectView
* all @SessionAttributes get exposed to the model before handler method execution
* @Event/ResourceMapping uniquely mapped to through event/resource id, even across controllers
* MultipartRequest is available as a mixin interface on (Native)WebRequest as well
* removed outdated "cacheJspExpressions" feature from ExpressionEvaluationUtils
* introduced common ErrorHandler strategy, supported by message listener container
* Jpa/JdoTransactionManager passes resolved timeout into Jpa/JdoDialect's beginTransaction
* HibernateJpaDialect applies timeout onto native Hibernate Transaction before begin call
* Spring's Hibernate support is now compatible with Hibernate 3.5 beta 1 as well
* Spring's JPA support is now fully compatible with JPA 2.0 as in EclipseLink 2.0.0.M7
* SpringJUnit4ClassRunner is now compatible with JUnit 4.5, 4.6, and 4.7
* SpringJUnit4ClassRunner once again supports collective timeouts for repeated tests
* deprecated @NotTransactional annotation for test classes in favor of @BeforeTransaction








:
Posted by 행복상자
Spring Source에서 새로운 툴을 하나 발표하려는 것 같다.
미국 시간으로 어제 "Roo Alpha 2 is now available for download" 라는 제목으로 글이 하나 올라왔는데, 생소한 이름의 툴이 하나 올라왔는데, 기존에 진행되었던 프로젝트와는 많이 생소한 내용이었다.

"Roo Alpha 2" 라는 이름으로 이미 Relesed 된 상태로, 이미 국내에서도 여러 개발자들이 관심을 갖고 살펴보고 있는 듯하다. 이는 SpringSource의 Tool Suite(STS)에 Roo Plugin으로 포함되어져 있고, 이들은 "introduction to Roo" 라는 블로그의 글을 통해서 "Roo"에 대해서 간략하게 소개하고 있다.
간단하게 Roo는  SpringSouce 오픈 소스 프로젝트이고, TDD를 위한 툴이고 이를 위해서 Shell을 개발자에게 제공한다. 그리고 Roo는 개발자가가 새로운 언어를 배우지 않고 쉽고 빠르게 그들의 Application을 개발 할 수 있도록 설계되었다고 한다.

Roo는 무료로 사용할 수 있는 툴인데, 이번주, 즉 5월 7일자(미국시간)로 무료로 다운받아 사용할 수 있다는 것이다. 이에 대해서 시간 제약과 같은 규제는 따로 없다.
우리 시간으로 5월 8일에 다운 받아 쓸수 있다는 말이다. (참조: http://www.springsource.com/products/sts)

Roo는 나에게는 아주 생소한 주제이다. 그래서 잠깐 구글링을 해보 았는데, 국내의 여러개발자들이 벌써 이를 테스트하고 분석하고 있는 중이었는데, 그중 특이한 것은 이 Roo가 갑자기 하늘에서 떨어진 것은 아니라는 것이다.
이미 일민(Toby)이가 이를 대한 소개를 한 글이 있었다. 2006년도에 TES2006에 참석해서 배운 내용을 정리했던 것인데 "TSE2006 넷째날 두번째 세션 - ROO"를 보면 이해에 도움이 될거라 생각된다.
그가 2006년에 Roo에 대해 알았다면, 이는 참 오래된 감춰진 프로젝트의 하나일 것이다.

그리고, "Introducing Spring ROO: Part 1" 의 글을 보면, 현재의 Roo에 대한 간략한 소개와 설치에 대한 설명들이 있다. 이름 참조하면 설치에 무리가 없을 거라 생각되고, 참고로 여기서는 A1 버전을 사용하였다.

그리고 지난주에 유럽에서 열렸던 SpringOne에서 발료되었던 세션중에 "Presentation: "Extreme Productivity in Application Development"을 보면 좀더 새로운 Roo에 대한 정보를 얻을 수 있을 것이다.

최근에 Roo에 대한 새로운 이름에 대해서 투표를 진행했는데, Roo도 괜찮은 이름인것 같다. 어떤 이름으로 다시 공개될지 모르지만 현재는 Roo이고, 이는 당분간은 유지 될거라 생각된다.
(투표에 관심있는 사람은 http://cloud.springsource.com/vote 를 한번 찾아가 보시길... )
Roo 1.0 Release는 6월 중순에 발표될거고, 1.0 GA버전은 올해말에 공개될 예정이다.

Roo를 사용하게 되면 어떤식으로 프로그램 방법이 바뀔지는 아직 감은 없지만, 많은 사람들이 관시을 가지고 있었던 프로젝트 였던만큼, 큰 반향을 일으킬 소지는 충분히 있다. 간단하게 작성된 소스들을 보더라도, AspectJ와 많은 Anotaion들이 사용이 된다. 중요한 것은 새로운 것을 익히고 쓰기 위해서는 기본에 충실해야 한다는 것이다. 이를 쓰기 위해서도 역시 기본적인 개념과 사용법에 대해서 익숙해질 필요가 있다.

아무리 좋은 도구라도 사용하는 사람이 익숙하지 않다면, 좋은 인상을 주기 어렵다. 새로운 것을 배우는데 익숙하거나 즐기는 사람이라면 다르겠지만, 자기가 하고 있는 분야만이 전부라고 생각하는 소아적인 개발자와 관리자를 깨우치기는 정말로 어렵기 때문이다. 그래서 "돼지목에 진주"라는 말이 있나 보다.

:
Posted by 행복상자
2008. 12. 7. 08:45

SpringFramework 3.0 Released (3.0.0.M1) 공부하는 것2008. 12. 7. 08:45

미국 시간으로 지난 12월 5일 스프링 프레임워크 3.0이 릴리즈 되었다.
지난 주에 미국에서 여렸던 SpringOne 2008 America를 마치자마자 바로 Release 시킨 것이라 생각이 든다. 이에 대한 변화들은 이미 SpingOne과 일민이(Toby)의 블러그를 통해서 알 수 있을 것이다. 아래에 링크들을 만들어 놓았다. 스프링 프레임워크의 전반적인 변화들을 알수 있을 것이다. 지금쯤 돌아가고 있는지도 모르겠다. 호주로...

일민의 SpringOne 2008 탐방기:

그리고 아래는 이번에 올라올 3.0.0.M1 버전의Change Log 이다. 변경된 사항들을 가장 쉽게 확인할 수 있을 것이다.

한가지 분명한 것은 Dynamic Language에 대한 지원이 점점더 커질 것이라는 것이다.
기능적으로 언어적으로 우세함을 따른 것이 아니라, 실용적인 면에서 좀더 개발을 편하고 쉽게 갈수 있다라는 측면에서 접근해야 한다는 것이다. 이러한 측면에서 새로운 것들, 특히 Ruby와 Grails는 분명 개발자들이 익혀야 할 시점이 곧 다가 올 것이다
.

(아래 로그 내용 참조)

SPRING FRAMEWORK CHANGELOG
==========================
http://www.springframework.org

Changes in version 3.0.0.M1 (2008-12-05)
----------------------------------------

* revised project layout and build system (module-based sources, bundle repository)
* updated entire codebase for Java 5 code style (generics, varargs, StringBuilder)
* updated to JUnit 4.5 and JRuby 1.1
* removed WebLogic 8.1 and WebSphere 5.1 support
* removed native TopLink API support (superseded by JPA)
* removed Commons Attributes support (superseded by Java 5 annotations)
* removed Jakarta JSTL support for JSP 1.2 (superseded by JSP 2.0)
* removed outdated Struts 1.x Action delegation support
* removed ContextLoaderServlet and Log4jConfigServlet
* deprecated form controller hierarchy in favor of @MVC form object handling
* deprecated JUnit 3.8 test class hierarchy in favor of test context framework
* introduced Spring EL parser in org.springframework.expression package
* introduced #{...} expression support in bean definitions
* introduced @Value annotation for embedded expression support
* introduced @PathVariable annotation for MVC handler methods
* introduced ShallowEtagHeaderFilter
* introduced AbstractAtomFeedView and AbstractRssFeedView
* introduced default value support for @RequestParam
* introduced @RequestHeader annotation for MVC handler methods
* introduced "spring:url" and "spring:param" JSP tags





 

:
Posted by 행복상자