달력

4

« 2024/4 »

  • 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
2008. 7. 5. 20:47

Spring Dynamic Modules 1.1.0 Released 공부하는 것/Spring Framework2008. 7. 5. 20:47

드디어 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의 지원으로 해결됨이 기쁜 일중에 하나이다.

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

'공부하는 것 > Spring Framework' 카테고리의 다른 글

Spring Framework를 이용한 Scheduler - Quertz에 대한 설명  (0) 2008.07.13
Spring Framework를 이용한 Scheduler 개발하기  (0) 2008.07.07
Spring에서 Root Application Context 정의하기  (0) 2008.06.30
Spring Configuration 사용법  (0) 2008.06.30
SpringSource Application Platform Beta Released: 자료추가  (0) 2008.05.05
:
Posted by 행복상자
2008. 6. 30. 22:50

Spring에서 Root Application Context 정의하기 공부하는 것/Spring Framework2008. 6. 30. 22:50

요즘 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과 같이 사용하면 된다.

오늘도 두서 없이 적었다.

'공부하는 것 > Spring Framework' 카테고리의 다른 글

Spring Framework를 이용한 Scheduler 개발하기  (0) 2008.07.07
Spring Dynamic Modules 1.1.0 Released  (0) 2008.07.05
Spring Configuration 사용법  (0) 2008.06.30
SpringSource Application Platform Beta Released: 자료추가  (0) 2008.05.05
SpringSource Application Platform  (0) 2008.05.02
:
Posted by 행복상자
2008. 6. 30. 00:55

Spring Configuration 사용법 공부하는 것/Spring Framework2008. 6. 30. 00:55

그냥 며칠동안 테스트 코드를 작성하면서, 발견한 사실들에 대해서 겸허히 쓴다.
일민이(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 는 "&"로 정의되어 있다. 

'공부하는 것 > Spring Framework' 카테고리의 다른 글

Spring Dynamic Modules 1.1.0 Released  (0) 2008.07.05
Spring에서 Root Application Context 정의하기  (0) 2008.06.30
SpringSource Application Platform Beta Released: 자료추가  (0) 2008.05.05
SpringSource Application Platform  (0) 2008.05.02
Spring Framework MVC application step-by-step  (0) 2008.04.26
:
Posted by 행복상자
2008. 6. 29. 09:39

Ruby on Rails 세미나에 다녀와서... 좋아하는 것/전시회, 세미나2008. 6. 29. 09:39

어제는 Roby 세미나에 다녀왔다.
김 정현 책인 2시경에 오라고 해서, 12시부터 자기는 Ruby 투터리얼 강의가 있는데 루비를 알는 사람들은 2시부터 참석하면 된다고 했다. 조금 일찍 도착한 나는 별다방에서 시원하고 단 음료를 시켜놓고, 홀로 요즘 공부하고 있는 자바 소스를 분석하고 있었다.

이젠, 가야지하고 포스코 사거리로 나섰다. 그리고 세미나가 열리는 빌딩을 찾아 갔는데, 이게 왠걸? 느낌이 이상했다. 건물 1층의 보안 요원은 그런 행사가 없다고 하며, 혹시 다른 건물이 아니지 확인해 주었다. 나도 이상해서 전화를 해보았다.
앗 이럴수가 세미나 장소는 가락시장역에 있는 소프트웨어 진흥원 건물이었다. 그 곳은 이전에 Spring 세미나가 열렸던 곳이라 찾는 데는 어려움이 없었다. 하지만 왜 장소를 잘못 알았을까? 참 미스테이한 일이었지만, 이유를 찾는데는 어려움이 없었다. 행사, 세미나 게시판에서 전년도 행사장 위치 소개를 이번 행사 약도로 잘못 보고 헛걸음을 친 것이었다.

암튼 행사는 엄청 늦었다.

행사는 소프웨어 진흥원 건물 5층에서 열렸다. 약 100명 정도의 참석자들이 모여있었다. 나름 준비해온 세미나 자료를 참석자들에게 열정적인 모습으로 설명하는 모습이 이상적이었다. 하지만, 전문적인 Speaker들이 아니기에, 하고싶은 말을 전달하는 과정이 수월해 보이지는 았았다. 그러나 인상적인 것은 자기가 좋아하는 것을 더 많으 사람들에게 전하려는 열정많은 정말 뜨거웠다. 그리고, 제대로 준비해서 전달할 수 있는 기회가 곧 오지 않을까 생각이 들었다.
이 사람들의 열정과 젊음이 정말 부럽다.

몇몇 주제는 낯 설었지만, 흥미로왔다. 그리고 누구나 마지막까지 자리를 지치는 사람들에게만 주어진다는 상품 추첨 시간은 긴장감이 돌았다. 겨우 책 5권 밖에 되지 않아서, 5%의 확률.., 역시나 나는 추첨 운은 없다. 기존에 책을 가지고 있는 사람들이 당첨되어서 책을 포기해 주었지만, 나에게는 기회가 돌아오지 않았다.

세미나 주제중에 JRuby와 Spring Framework의 개발시 사용에 대한 발표가 있었다. 행사장에 많은 사람들은 자바로 개발을 해본 사람들이 많았고, 나역시 관심이 있는 주제이기도 했다. 왜냐하면, Rails의 생산성은 익히 알려져 있기 때문이다. 기기에다 자바 기술의 탄탄함까지 더해진다면이라는 가능성을 항상 염두에 두고 있기 때문에 Ruby와 Rails에도 관심을 가지고 있는 것이다.
세미나는 단순했다. "이렇게 이렇게 사용하면 되지 않을까요? 고객이 원하면 이렇게 하면 되지요" 라는 정도의 이해로 세미나를 진행한다는 것은 무리라는 생각이 들었다.
RubyOnRails의 입장에서 보면, 기존이 자바 Enterprise 기술은 경쟁자일 뿐이고, 극복하지 않으면, 커 나가지 못한다는 입장을 가지고, 타 기술에 대한 정확한 이해없이 융합 또는 양 기술의 동시 사용에 대해서 논하는 것은 시기 상조가 아닐까 싶었다.
정확하게는 Ruby라는 기술이 더 좋은데, 할 수 없이 자바를 사용해야 하는 것처럼 들렸다. (아니라면 정말 죄송)
나도 이야기를 들으면서, 그런데 왜 자바의 기술들을 쓰려고 할까라는 생각이 연신 들었다.
이에 대한 명확한 해답이 없으면, 아마도 한국에서 Ruby라는 기술의 확산은 그리 쉬운 길이 아닐것 같다. 결국 고객들을 설득해 나가야 한다. 고객이 원하는 것을 해 줄수 있다면, 루비든 자바든 다 같이 하나의 툴일 뿐이다.

그동안 많은 새로운 툴들이 나와서 개발자들이 편해질 거라고 했지만, 편해진 시간 만큼 개발자는 더 많은 일과 프로젝트를 하고 있을지도 모른다. 우리들의 Boss는 결코 멍청하지 않다. 고객은 개발시에는 무지하고 멍청해 보일지도 모르지만, 산출물이 나오는 시점에는 어는 누구보다도 예리하고 날카롭다. 그리고 천재적이기까지 하다. 항상 새로운 일들을 준비해 준다.
개발자들은 그러한 천재들을 상대하기 위해서 더 많은 공부와 자기가 습득한 기술들의 단련이 필요하고, 더불의 설득력을 길러야 할 것이다. 기대치 관리를 포함해서 말이다. (정말 두서 없이 글을 썼다.)

 
 

'좋아하는 것 > 전시회, 세미나' 카테고리의 다른 글

Google Cloud Summit 2018  (0) 2018.11.12
국립 과학관, 빛의 신비전을 다녀와서...  (0) 2009.01.07
웹 애플리케이션 컨퍼런스를 다녀와서...  (0) 2008.10.26
세미나 소개: Ruby on Rails 세미나  (0) 2008.06.27
어도비 RIA World 2008을 다녀와서..  (0) 2008.03.23
:
Posted by 행복상자

티스토리툴바