달력

9

« 2019/9 »

  • 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
  •  
  •  
  •  
  •  
  •  



스프링프레임워크를 사용해서 Restful API를 개발할때, RequestHeader 정보를 가져오는 방법이다.

요즈음에 대세가된 SpringBoot를 이용할 경우에 다른 설정은 크게 필요하지는 않다.

 

"@RestController"를 이용하여, 컨트롤러를 선언해주고, "@GetMapping" 어노테이션을 이용하여, "http://localhost:8080/headerinfo" 라고 호출하였을때, 실행되도로 정의했다. 이때 호출되는 RequestHeader값은 "@RequestHeader" 어노테이션을이용하여 "headers"라는 변수를 통해서 넘겨받을 수 있다.

package net.happyzoo.happzoo;

import lombok.extern.slf4j.Slf4j;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.http.HttpHeaders;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;
import reactor.core.publisher.Mono;

import java.util.Map;

@SpringBootApplication
@Slf4j
public class HappzooApplication {

@RestController
public static class GetControllerPractice
{
@GetMapping("/headerinfo")
Mono<Map<String, String>> getHeaderInfo(@RequestHeader HttpHeaders headers)
{
log.info(headers.toSingleValueMap().toString());

return Mono.just(headers.toSingleValueMap());
}

}


public static void main(String[] args) {
SpringApplication.run(HappzooApplication.class, args);
}

}

위는 Sample 코드이며, Lombok을 이용하여 @Slf4j를 선언해주면, 로그를 남길수 있도록 했는데, Lombok를 사용하지않으면, 선언에서 제외하면 된다.


실행 결과는 다음과 같이 Map의 형태로 반환해서 Mono로 전달하면 Client에서 결과값을 받을수 있다.

return Mono.just(headers.toSingleValueMap());


Terminal에서는 

  curl -X GET http://localhost:8080/headerinfo

와 같이 명령을 실행해서 호출하거나, Chrome 브라우져에서 실행해보면 확인할 수 있다.

IntelliJ에 내장된 Rest Client를 이용해서 호출한 결과이다. Json의 Object형태로 결과를 받아왔다.




Posted by 행복상자

댓글을 달아 주세요

스프링 프레임크를 사용하기 시작한지는, 만 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 행복상자

댓글을 달아 주세요

며칠전에 블로그를 통해서, SpringSource Tool Suite(STS)의 무료 공개에 대해서 언급했었는데, 이제 공식적으로 무료로 공개한다고, 지난 5월 7일자(미국 시간)로 블로그의 "SpringSource Tool Suite is Now Free!" 라는 제목의 글을 통해서 발표했다.

글의 내용을 잠시 읽어보면, Rod Jonson이 지난 SpringOne Europe에서 약속하였던 것을 이행한다는 이야기이다.
그리고 이제부터는 SpringSource Tool Suite (STS)의 정식버전을 무료로 사용할 수 있다는 내용이다.
또한, Christan Dupuis의 최근의 Blog에 추가된 새로운 Feature(2.1.0.M1)들을 소개한다고 한다.

지난 번에는 블로그를 통해서는 Roo가 STS의 한 Feaure로 들어가있고, Roo를 사용해보기 위해서는 STS를 설치해보아야 한다고 이야기한적이 있는데, 이는 2.1.0.M1 버전 부터 가능할 거라 생각된다.

내가 STS에 관심을 갖고 있는 것은 SpringDM과 OSGi번들로 되어 있는 프로젝트 또는 개발된 Application을 제대로 지원하고 있는 툴이 없기 때문이다. 내가 작년부터 진행하고 있는 프로젝트에 도움이 되지 않을까라는 기대 때문에 이전부터 관심을 두어 있었다.

하지만, 아직 설치와 테스틀 해보지 않은 상태이므로, 툴의 장점을 알아가야 하는 과정을 밟아야 한다.
개발에 직/간접적으로 많은 도움을 줄거라는 기대가 있기 때문에, 조만간 날 잡아서 설치해볼 생각이다.

STS는 "download SpringSource Tool Suite"에서 다운 받을 수 있다.


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 행복상자

댓글을 달아 주세요

내가 현재 진행하고 있는 프로젝트는 Spring Dynamic Modules 1.1.2를 기반으로 개발하고 있다. 그리고 이를 기반으로 다른 솔루션 또는 Web Application들이 개발되고 있다.

지금은 지난 말까지 개발된 Framework의 일부 Architecture와 모듈을 Refactory중에 있다. 이의 필요성은 아마도 Spring DM Server가 나온다면, 사라질지도 모른다. 개발하고 있는 Core가 Spring DM Server와 거의 유사한 Architecture를 하고 있기 때문이다. 아마도 Spring DM Kernel만 있다고 누군가가 같다고 할지도 모르지만, Spring의 많은 기능을 얻어다 사용하기 때문에 이를 갈 수는 없고 많은 혜텍을 입었다고 할 수 있다.

지난 주에 Spring Dynamic Module 1.1.3이 발표되었다.
몇가지 변경된 사항을 살펴보았는데, 크게 바뀐 부분들은 눈에 들어오지 않는다.

아래는 Spring Dynamic Module의 Change Log이다.


Changes in version 1.1.3 (2009-02-13)
-------------------------------------

General
* various documentation improvements and fixes

Package org.springframework.osgi.context
* improved proxying of classes that are boot delegated outside the OSGi environment

Package org.springframework.osgi.io
* fixed manifest headers parsing problem when dealing with nested whitespaces
* fixed handling of optional required bundles
* improved OsgiBundlePatternMatchingResolver to return ContextResources
* changed OsgiBundlePatternMatchingResolver#findResources(String) visibility to protected

Package org.springframework.osgi.service
* fixed visibility issue when invoking non-public proxied methods
* improved waiting code to deal with spurious or accidental wakeups
* fixed issue with OsgiServiceProxyFactoryBean that caused autowiring to fail in some cases

Posted by 행복상자

댓글을 달아 주세요

간만에 Spring-DM 사이트(www.springframework.org)에 들어갔더니 사이트가 여러모로 개편이 많이 되어 있었다.

현재 안정화 버전은 Spring-DM ver. 1.1.1로 제공되고 있고, Spring-DM을 이용하여 개발에 참조할수 있는 어러가지 관련 글들의 링크들이 올라와 있었다.

아래는 http://springosgi.googlepages.com/ 에 올라와 있는 글인데 Spring-DM을 시작하는 방법들을 소개하고 있어서 가져왔다.
화면 스크린 샷도 같이 있어서 이해하는데 도움이 많이 될수 있을 것 같다.

Table of Contents
I. Spring-DM Getting Started
    1. Prepare Eclipse/Spring-DM environment

    1.1 Prerequisite

    1.2 Create Spring-DM Target Platform project structure

    1.3 Configure Maven using Eclipse External Tools

    1.4 Test Spring-DM Target Platform

    1.5 Creta Spring-DM User Library (class path)

2. Logging and Tracing with Eclipse PDE and Log4J

    2.1 Configure Logging and Tracing with Log4J

    2.2 Configure Eclipse PDE Tracing

3. Implement Simple Spring-DM service

    3.1 Create Spring-DM service project

    3.2 Implement Spring-DM service

    3.3 Configure Spring-DM service

    3.4 Deploy Spring-DM service

    3.5 Package Spring-DM service

4. Integration Testing with Spring-DM

    4.1 Develop Integration Test

5. Develop and deploy Spring-MVC (OSGi-fied) project

    5.1 Create web project as Eclipse plug-in project

    5.2 Define OSGi specific deployment configuration

    5.3 Deploy Spring-MVC project into Spring-DM Target Platform.

6. Develop and deploy JSF based application

         6.1 Create and deploy JSF project as Eclipse plug-in project
Posted by 행복상자

댓글을 달아 주세요

Spring Dynamic Module 1.1.1 이 정식으로 Release 되고, 약 1달이 지났다.
며칠전에 새롭게 1.2.0 M1 버전이 릴리즈 되었다. 빠르게 업그레이드 된다는 점도 있지만, 이는 아직 안정화가 안되어 있다는 반증도 된다.

현재 내가 진행하고 있는 프로젝트는 1.1.1을 사용하고 있다. 아마도 정식으로 1.1.2가 나오기 전까지는 이 상태로 유지해야 할 것 같다.

아래는 이번에 추가되거나 수정된 항목이다.
DM을 위한 MVC예제가 수정된 부분이 눈에 띈다.

Changes in version 1.2.0 M1 (2008-09-05)
----------------------------------------

General
* added new annotation-based, Spring-MVC sample
* removed petclinic sample (superseeded by simple-web-app and web-console samples)
* improved sample wars packaging
* improved framework behaviour when running in environments with Java 2 security enabled

Package org.springframework.osgi.context
* added reporting of Errors raised during delegated refresh in AbstractDelegatedExecutionApplicationContext

Package org.springframework.osgi.extender
* fixed bug related to enabling Spring-DM annotation depedency processing
* improved annotation injection processing
* improved extender configuration thread-safety
* fixed potential race condition in asynchronous waiting for service dependencies

Package org.springframework.osgi.io
* improved existence check for bundle resources
* improved jar space pattern matching when the root is not specified
* fixed classpath pattern matching on certain resources when the default Bundle-ClassPath entry (.) is not specified

Package org.springframework.osgi.service
* changed the proxying classloader strategy to address package dependency visibility
* fixed usage of incorrect class loader for imported services with client thread context class loader management
* fixed intermittent deadlock that appeared in some cases betweem importers and exporters during shutdown

Package org.springframework.osgi.web
* improved web extender configuration thread-safety
* improved web extender initialization by using an asynch model for cases with out-of-order dependencies

그리고 레퍼런스 가이드는 여기를 참조하면 된다.
http://static.springframework.org/osgi/docs/1.2.0-m1/reference/html/


Posted by 행복상자

댓글을 달아 주세요

정말 오래 간만에 글을 쓰게 되는 것 같다.
미국 출장을 갔다 온지 한달이 넘었는데, 이제야 내 블러그를 찾게 되었다.
뒤 돌아보면 한달은 그리 길지는 않은데, 정말 무심하기도 하지...

출장 후에, 이것 저것 바빴었다. 해결해야 할일도, 해야할 일도 모두 두배로 늘어나 있었다. 그리고, 못 갔던 휴가도 가야했기에....

지난 주는 후배가 운영하는 블러그에 잠시 들렀더니, "SpringDM과 차세대 OSGi"라는 제목으로 글이 올라와 있었다. 관심이 있어서 읽어보고 동료들과 공유를 하기도 했다.

회사에서 현재 진행하고 있는 프로젝트는 OSGi를 이용하는 프로젝트인데, Spring-DM을 그 기반으로 사용하고 있기에 신뢰성과 안정에 주변에서 큰 관심들을 가지고 있다.

블러그의 내용을 요약하면, Spring-DM 스펙이 OSGi 4.2스펙 표준으로 채택될 가성성이 높다라는 글이다. 자세한 내용을 블러그의 내용을 보면 알것이고, 간략하게 몇가지 내용만 설명하려고 한다.

현재, Spring Dynamin Module를 개발하고 있는 몇몇 개발자들이 OSGi Appliance에서도
핵심적인 역할을 하고 있는 것은 익히 잘 알려져 있는 사실이다.
그리고, Enterprize용으로 WAS를 만드는 IBM과 BEA(오라클로 최근에 인수)도 이를 적극적으로 지원하고 있다. 그럴만도 한것 이 Tuxedo를 개발 판매하고 있는 IBM은 OSGi개발에 핵심적인 역할을 하고 있고, 소스 코드를 Eclipse 재단에 무료를 기증한 바 있기에, 여기서 만들어진 Eclipse-equnox는 Eclipse를 성공 케이스로 하여 많은 곧에 적용되고 있는 상황이다. (사실 Eclipse 소스 코드도 IBM에서 오픈한 것입니다. Eclipse의 핵심 Architect역시 IBM 소속입니다.)
 
BEA는 Weblog을 판매하는 회사이지만, Spring Framework를 자사 솔루션에 최후선적으로 지원하고 있습니다. (그 회사 사장이 인터뷰한 기사들을 보면, 얼마나 스프링에 데해서 친근감을 가지고 있은지 알 수 있지요.) 더군다나 Spring Framework의 컨설팅과 유지보스를 하고 있습니다. 이는 Spring에 대한 신뢰성과 자사 제품의판매에 도움이 될거라는 확신 때문이다. 요즘은 OSGi를 자사 WAS에 적용하기 위해서 많은 노력을 하고 있는듯 하다.
 
아래 그림은 Equinox를 적용하려고 하는 개발사들에 대한 그림인데,
서버쪽에서 OSGi를 지원할 경우는 요즘은 Enterprise OSGi라고 하기도 한다.
OSGi대신에 OS-JEEi라고도 하는데, 아직은 널리 알려지 있지는 않았지만 J2EE에 OSGi를 적용한 것이라 생각하면 된다.

사용자 삽입 이미지


Posted by 행복상자

댓글을 달아 주세요

지난번에는 Quartz를 사용하기 위한 개략적인 설명과 라이브러리 사용을 위한 문서들의 위치에 대해서 이야기 했었다.

오늘은 Quartz사용시 알아야할, 기본적이지만 정말로 중요한 개념인 Trigger와 JobDetail에 대해서 이야기 하려고 한다.

먼저, Quartz에서 Scheduling 할 수 있은 범위 또는 Scope에 대해서 설명하고, 이어서 두가지에 대해서 말하려 한다.

[Job Scheduling]
  • on certain days of the week (주중의 지정한 날: 특정 요일)
  • on certain days of the month (달주의 지정한 날: 특정 날짜)
  • on certain days of the year (연주의 지정한 날: 특정 날짜)
  • not on certain days listed within a registered Calendar (such as business holidays)
  • repeated a specific number of times (반복횟수)
  • repeated until a specific time/date (종료 시점 지정)
  • repeated indefinitely (무한 반복)
  • repeated with a delay interval (다음 실행을 위한 타임 인터벌)

    위에서와 같이 스케즐러를 실행하기 위한 모든 범주들에 대해서 쿼츠는 커버 가능하다.
    여기서 Job(JobDetail)과 Trigger에 대한 개념을 알아야 하는데,

    먼저 Job에 대해 설명하면 Job는 실행해야 할 작업으로 이해하면 된다. 예를 들면 메이을 보낸다든지, 필요없는 로그 파일들을 정리하거나, 시스템의 자동화된 작업들을 들수 있다.
    여기서는 실행되는 시간에 대한 개념은 없고, 단순히 일의 단위만 생각하면 된다.

    Trigger는 Job의 실행을 위한 조건들이라고 생각하면 이해가 쉽다. 실행될 시간, 반복횟수 또는 Interval time등 여러가지 실행 조건들을 생각하면 되는데, Sheduler이니까 시간에 대한 조건들을 포함하고 있다.(시간 기반으로 동작)

    Quartz기반으로 실행할 작업을 만들려면, Job과 Trigger를 각각 정의해서 묶어주면 된다.
    여기서 Job은 Interface 정의되어 있다. 우리는 이를 상속받아 원하는 작업들을 정의하게 된다. 그리고 Quzrtz의 Sheduler가 실행될때, Job에 대해 이해할 수 있도록 JobDetail를 정의하면 된다.

    .Job interface

    void execute(JobExecutionContext context)


    .JobDetai 클래스의 생성자

    JobDetail(String name, String group, Class jobClass) 

      위 코드에서 name과 group는 Job를 위한 Job이름과 JobGroup를 의미한다. 이는 관리를 편하게 하기 위한 것인데, 필요시 이를 이용하여 Job의 검색이 가능하고, 만약 null값을 넣어 준다면, DEFAULT 그룹명이 할당 된다.

    Trigger클래스는 JobDetail클래를 이용하여 정해진 시간에 실행이 되도록 스케즐러가 관리하는데, 이는 아래와 같은 코드를 통해서 Job에 대한 정보들을 가져오게 된다. 아래 코드는 Job의 name와 Grouup명만 있을 뿐, 직접적으로 할당하지 않지만, 내부적으로는 위에서 정의한 job의 name과 group name을 참조하여 가져오게 된다.

    Trigger(String name, String group, String jobName, String jobGroup)

    여기도 name과 group가 있는데, 이는 Trigger의 이름과 group 명이다.

    다음에는 코드를 이용하여 실제로 Job과 Trigger을 정의하고 사용하는 방법에 대해서 설명하려 하다.

  • Posted by 행복상자

    댓글을 달아 주세요