달력

1

« 2021/1 »

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

드디어 Spring Dynamic Module 1.1이 발표되었다. 공식적으로는 미국 시간으로 7월 4일 어제였다. 그런데 바로 하루전인 7월 3일 Spring Dynamic Modules 1.0.3 정식 버전의 정상적으로 Release 되었는데 말이다.

Spring Dynamic Module의 정식이름은Spring Dynamic Modules for OSGi이다. 하지만 작년까지만 해도 우리들에게는 Spring OSGi라는 이름으로 더 잘 알려져 있었다. 그러나 OSGi Appliance의 공식적인 허가 없이는 OSGi라는 명칭을 사용할 수 없기에, 지금은 Sprig Dynamic Module로 사람들에게 소개된 것이다.

다운로드 가능한 위치는 아래와 같다.
    - spring-osgi-1.1.0-with-dependencies.zip
    - spring-osgi-1.1.0.zip

위 링크와 같이 두개의 버전으로 제공이 되는데, dependencies 라고 되어 있는 모듈은 참조를 하고 있는 관련 라이브러리(.jar)파일과 소스를 포함하고 있어서 개발 환경을 구축할 때, 손쉽고 시간을 절약하도록 되와준다. (개인적으로 추천)

Spring-DM 1.1버전과 1.0.3 버전이 하루 차이를 두고 동시에 발표되었는데, 이른 두 버전의 Feature가 다르기 때문이다. 쉽게 이야기 하면 1.1과 1.0의 Feature가 다른데, 1.0버전의 새로운 Feature는 다음과 같다.

The new 1.1.x series introduces several new features over the 1.0.x branch, such as:

* web support (Servlet, JSP, Taglibs) for OSGi applications
* Spring-MVC integration
* classpath scanning
* customization hooks for Spring-DM extender and web extender
* event notifications for OSGi service importers and application contexts
* refined OSGi proxy infrastructure
* 'greedy-proxy' functionality for OSGi collections
* integration with SpringSource Bundle Repository
* support for custom locations for Spring powered bundles
* pluggable mechanism for determining service dependencies
* access to native OSGi ServiceReference for OSGi importers
* new web sample
그리고 몇가지 버그 수정들이 수정됨.

위의 내용은 별도로 번역을 하지 않아도 이해가 가능할것이다. 기능에 대한 새로운 Feature들에 대한 설명인데, 이는 Spring Dynamic Module의 Reference Documentation 참고 하면 된다. (Chapter 3 What is new?)

그래도 간락하게 설명을 하면.
* OSGi상에서 Web Application 지원(Web Serport)
    - Appach Tomcat and Jetty와 같은 Container 지원
    - Spring-DM은 Servlet을 사용하는 WAR 파일을 지원하고,
    - JSP와 Taglib를 위해 거의 변경없이 바로 사용할 수 있게 해준다.
         ==> 참조 :
Chapter 8, Web Support
    - Spring-MVC를 OSGi 환경하에서 지원함
        ==> 참조 : 
Section 8.7, “Spring-MVC Integration”
    - Classpath Resource 탐색지원 :  classpath: and classpath*: 
       ==> 참조: 
component scanning
   - 다양한 extender를 위해 default configurantin 을 쉽게 변경할 수 있음
   - Spring Application의 Lift cycle의 인지 아래 발생하는 Event를 받을 수 있음
   - Proxy Creation(생성)의 성능향상으로 번들의 Package wiring이 좋아짐.


일부에서, 스프링 DM을 이용한 프로젝트에 대해 우려를 많이 한다.
몇가지 알려진 문제들이 있는데, 이들은 이번에 발표된 1.1버전에서 많이 해결되었다.
가장 큰 문제는 Thread 지원과 Class Loder에 관한 부분들이었는데, 1.1의 지원으로 해결됨이 기쁜 일중에 하나이다.

역시 공부할 것은 자꾸 늘어간다. 스스로 실력없음을 항상 느낀다. 스프링의 방대한 소스를 보면서 더 많이 느낀게 되지만, 그래도 즐겁다.

TAG Sping-DM
Posted by 행복상자

댓글을 달아 주세요

요즘 Spring Framework의 소스 코드를 보는 시간이 많아져서  즐겁기도 하고, 배움의 깊이가 깊어지는 것 같아, 행복하기도 하다.(자아 도취 ?, 만족? )

내가 개발자의 길을 고집하는 것은 좋아하는 일을 업으로 살아갈수 있다는 것이다. 좋아하는 것을 한다는 것은 배움에 있어 거부감없이 이해하는 만큼 흡입할 수 있다.
잘 된 코드를 보고 배울 수 있다는 것은 기능에 대한 이해와 더불어 더 많은 것을 보도록 해준다. 예전에 일민이(Toby)가 소스를 보고 공부하라고 했을때는 별로 필요가 없기도 하고, 기능만 알면 개발할 수 있는데라는 얇팍한 마음에 무시했었다. 그러나 지금 보니 참 많은 것을 얻을 수 있었는데, 좀더 빨리 시도할 걸이라는 마음이 든다.

어제는 Spring Framework에서 Singleton 또는 Prototype으로 Bean을 등록하고 사용하기 위해서 getBean() 메소드를 이용하는 것에 대해서 공부했다.
Bean은 기본적으로 ApplicationContext에 HashMap에 담겨져 있고, 필요시 불리우게 되는데, 이는 ApplicationContext를 통해서 Singleton처러 한개의 인스턴트로 동작하기 때문이다.

이에대해서는 일민이가 스프링 포럼을 통해서 질문에 답한 글을 올렸는데, 쉽게 잘 정리 되어 있다.(필독이다.)


web.xml을 통해서 Root ApplicationContext 로 여러 파일들을 읽어 오려면,

 <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
          /WEB-INF/applicationContext.xml  /WEB-INF/schedulingContext-quartz.xml
     </param-value>
 </context-param>


와 같이 추가해 주면, 클래스 패스 아래 정의된 두개의 설정 파일을 읽어 오게 된다.

아니면, 빈 설정 파일에서 다른 설정 파일들을 import해서 읽어 올수 있다.

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>
xml 파일이 커지거나 작업별로 분리할 필요가 있을때 유용하다.

그리고, 다음과 같이 ApplicationContext Interface를 통해서 여러 설정 파일들을 읽어 올수 있다. 이는 테스트할 때 편리하다.

ApplicationContext context = new ClassPathXmlApplicationContext(
        new String[] {"services.xml", "daos.xml"});
BeanFactory factory = context;

Spring MVC를 이용하여 Web Application을 개발할 경우에는
<servlet>
      <servlet-name>image</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <load-on-startup>2</load-on-startup>
</servlet>

와 같이 설정파일에 정의하게 되는데, Spring의 DispatcherServlet에서 서블릿을 정의하고, 이를 위한 Config 파일을 읽을 때는 기본적인 Naming rule을 따르는데, {servlet-name}-servlet.xml 같은 형식의 파일을 생성하고 정의하면 된다.
위의 경우라면 image-servlet.xml과 같이 사용하면 된다.

오늘도 두서 없이 적었다.

Posted by 행복상자

댓글을 달아 주세요

그냥 며칠동안 테스트 코드를 작성하면서, 발견한 사실들에 대해서 겸허히 쓴다.
일민이(Toby)는 나보고 또 Spring Framework Developer Reference를 읽어보라고, 아프게 충고를 했다.

먼저, Test코드를 작성하다 보니,
BeanFactory 의 사용법과 ApplicationContext 의 사용법이 다르다는 사실을 발견했다.
사실 ApplicationContext는 BeanFactory의 인터페이스를 상속받아 만들어진 인터페이스이다. 따라서, ApplicationContext는 BeanFactory의 모든 동작을 포함하고 있고, 비슷하게 동자을 하도록 도와준다. 둘 모두 getBean() 메소드를 사용해서 Configuration을 위해 작성한 XML파일에서 정의한 Bean을 얻을 수 있다. 아까도 이야기 했지만, ApplicationContext Interface는 BeanFactory Interface의 확장이다.

ApplicationContext와 BeanFactory Interface간의 차이점은 Singleton 빈의 로딩하는 방법에 있다. BeanFatory는 getBean() 메소드가 호출될 때까지 Bean의 생성을 미룬다. 반면에 ApplicationContext는 Singleton 빈을 미리 로딩함으로 그 빈이 즉시 사용이 가능하도록 보장해 준다.

일반적인 테스트 코드를 작성할때는 두개의 차이가 거의 없을것이다. BeanFactory는 테스트 코드를 작성하기에 매우 유용하지만, 두 Interface의 차이를 알지 못하면, 이상하게 여길수도 있다. 최근에 Scheduler를 작성하게 되면서, 테스트 코드를 작성한 적이 있는데, Quertz의 Thread가 생성이 되어서 동작을 해야 하는데, 동작을 하지 않다가 getBean("scheduler")를 실행시켜줘야만 동작을 한는 것이었다. (BeanFactory 사용시)
그러나, ApplicationContext의 사용시는 ApplicatiionContext의 인스턴트가 생성되면, Quartz의 Thread가 실행되어 정해진 시간마다 Job을 실행하는 로그를 찍었다. 이유는 위에서 설명한 이유때문이다. (테스트시 ApplicationContext를 사용할 이유가 하나 늘었다.)

그리고 또하나 발견한 것은 getBean("beanId")을 통해 Bean의 reference를 얻어 올수 있다. 하지만, 가져온 Bean의 형이 내가 생각했던 것과는 다를 수도() 이는 Bean의 원 클래스에서 반환하는 오프젝트가 반환되기 때문이다.

[AbstractApplicationContext 코드 중에서]
public Object getBean(String name) throws BeansException {
  return getBeanFactory().getBean(name);

 }


만약, Factory 자체를 반환하기를 원한다면, "&"를 "beanId"앞에 붙여서 사용하면 된다.
이렇게 말이다. ==> getBean("&beanId)
이를 가르쳐 주면서 reference guide 를 잘 살 펴보라고 한다. 그래서 살펴보았더니. 딱 2줄에 걸쳐서 설명이 되어져 있다. Spring In Action에는 설명이 아예 안 되어 있다.

[BeanFactoryUtils코드 중에서]

public static boolean isFactoryDereference(String name) {
  return (name != null && name.startsWith(BeanFactory.FACTORY_BEAN_PREFIX));
 }


이 코드은 사실 AbstractBeanFactory 클래스에서 사용되는 메소드이다. 그리고
BeanFactory.FACTORY_BEAN_PREFIX 는 "&"로 정의되어 있다. 
Posted by 행복상자

댓글을 달아 주세요

며칠전에 SpringSouce에서 새로이 발표한 SpringSource Application Framework에 대해서 글을 소개한 적이 있다. 지난 30일 팀 블러그를 통해 발표 되었었다.
이는 Dynamic Module Kernel(DM-Kernel)을 기반으로 만들어진 현재는 베타버전의 SpringSource의 Application Platform이다.


잘 만든 Architecture도 결국은 어떻게 Deploy하고 관리 할 것이냐에 대한 고민을 하게 되는데, 이는 새로 만든 모듈들과 기존에 동작하는 모듈간에 조화로움이 관건이다.(버전 관리와 Dependency의 문제)

www.springframework.org 에 들어가 보니, Application Platform에 대한 글과 자료들이 새로 올라와 있어서 흩어 보았는데, 리눅스와 윈도우 환경에서 설치와 사용에 대한 Guide와 개발자 매뉴얼이 올라와 있어 새로운 Platform에 대한 이해에 큰 도움이 될거라 생각이 든다.
Web Site에 올라온 자료들의 목록과 링크는 다음과 같다.




각 번들에 필요한 기능들을 어떻게 가져오고 노출 시킬 것인가에 대해해, 요즘 고민 중인데, 분석을 하면서 아이디어를 얻어야 할 것 같다.
현재 내가 하고 있는 프로젝트는 공통 모듈들 개발 해야 하는데, 각 공통 모듈을 이용해서 개발해야 할 솔루션의 내부에도 외부로 노출 시켜야 할 서비스 부분이 분명 존재한다. 이를 어떻게 다른 쪽에 인지 시킬 것인지, 그리고 어떻게 가져다 써야 할 것인지에 대한 고민 중이다.



위와 같이 직접 불러다 사용하거나, 아니면 아래와 같이 공통의 라이브러리를 따로 만들고 각 번들에서 직접 호출해서 사용할 수도 있을 것이다.




Posted by 행복상자

댓글을 달아 주세요