Spring Framework 2.5 : New and Notable 프로그래밍

Spring 2.5 정리
- java6 지원 : jdbc 4.0, JMX MXBeans, JDK ServiceLoader API
jdk1.3 지원 안 함
- JDBC 지원 개선 : Native connections(java.sql.Wrapper), LOB Handling(setBlob/setClob), SQLException 하위클래스 추가
- 그 외 JDBC 개선된 점 : SimpleJdbcTemplate, SimpleJdbcCall, SimpleJdbcInsert, MSSQL, MySQL, PostgreSQL, Oracle 에러 코드 매핑 추가

- Java EE 5 지원
  - Java EE 5 API 통합 : Servlet2.5, JSP2.1, JSF1.2, JTA1.1, JAX-WS2.0, JavaMail1.4
  - BEA WebLogic 8.1이상, IBM WebSphere 5.1이상 지원(J2EE 1.4, 1.3 계속 지원...)
  - 스프링 Component model은 Java EE 5에 핵심적인 어노테이션을 가공처리한다(?)
    JSR-250 인젝션, 라이프사이클 어노테이션 : 자바 플랫폼상의 통상적인 어노테이션
    EJB 3.0 어노테이션 : 트랜잭션, @EJB, 기타 인젝션 어노테이션
  - 통합된 EL지원
    JSF 1.2 : SpringBeanFacesELResolver
    JTA 1.1 : 신규 TransactionsSynchronizationRegistry 지원
  - RAR 파일 지원(스프링 애플리케이션을 RAR파일로 디플로이 할 수 있음)
     J2EE 1.4, Java EE 5(JCA1.5)
     메시지나 스케쥴링잡 등에 의한 비-웹디플로이 유닛(headless WAR 대체, 스프링 ApplicationContext.xml파일을 참조하기 위해 META-INF/ra.xml 추가, JTA TransactionManager와 MBeanServer와 같은 애플리케이션 서버 서비스에 액세스 할 수 있음)
    - 공식적으로 IBM WAS 6.x 지원(transaction suspension포함, WebSphere 6.0.x, 6.1.x)
      - WebSphereUOWTransactionManager사용(애플리케이션 코드를 오염시키지 않고 IBM API를 사용할 수 있도록 스프링 JtaTransactionManager을 대신함)

- Spring & OSGi
    Open Services Gateway initiative
    자바 동적 모듈 - 엔터프라이즈 자바의 미래를 위한 핵심
    서브시스템의 깨끗한 isolation, Versioning, Hot deployment

    Bundle(중심적인 패키징 유닛) : Versioned JAR, 노출될 타입 전달, 임포트될 타입 구체화, 런타임에 시작, 정지, 갱신될 수 있음
    Spring 2.5 jar는 OSGi Bundle임(MANIFEST.MF의 headers, 프레임웍을 위한 궁극의 모듈화(필요할 때만 로드)
    Spring Dynamic Modules for OSGi Service Platforms프로젝트로 통합
    각 번들당 한 개의 ApplicationContext
    OSGi 서비스 레지스트리와 통합
    입증된 스프링 컴포넌트 모델을 입증된 OSGi 모듈 시스템과 결합
    SpringSource 애플리케이션 플랫폼은 OSGi의 generic 미들웨어 커널에 기초함
- Spring on OSGi vs Spring on Java EE
스프링은 양쪽 케이스에 양립적인 프로그래밍 모델 제공(환경에 종속적이지 않은 POJO, 스프링의 주요 장점으로 가트너에 의해 분류된 환경들 간 이식가능)

Annotations
  - java 5.0에 소개, 소스코드에 메타데이타 추가
  - 스프링은 엔터프라이즈 서비스를 위한 어노테이션 제공(트랜잭션 관리와 JMX) - Spring 1.2때부터..
  - DI 지원을 위한 포괄적인 어노테이션 소개

- DI를 위한 어노테이션의 목적
어노테이션은 클래스, 메서드, 필드에 적용
인젝션 포인트 표시, 어느 Value가 인젝트 될지 결정
메서드위의 어노테이션은 어떤 argument가 인젝트될 지 표시함(다중 arguments 가질수 있음)
필드위의 어노테이션은 인젝트될 Value를 표시함
메서드 argument상의 선택적인 어노테이션은 의존성을 결정하는 방법에 대한 정보를 제공함
클래스 위의 어노테이션은 스프링에 의해 관리될 컴포넌트를 표시함
- 장점 : 외부설정을 제거하거나 감소시킴. 보다 간결한 메카니즘(어떤 것이 인젝트되고, 어디에 어노테이션의 위치로 어디에 인젝트할 것인지를 표시할 수 있음)
- 단점 : per-type not per-instance. 어노테이션이 없는 레거시 코드에서 동작하지 않음. 설정을 변경할 경우 자바코드를 재컴파일 필요. 내부 간단한 타입을 객관화하는 데는 적합하지 않음(?)

- 스프링2.5의 어노테이션 기반 DI를 위한 선택들
@Autowired : 스프링 어노테이션 syntax, 어노테이션 기반 모델을 사용한 경험으로 입증된 스프링 모델 통합
@Resource : JSR-250 / EJB3 model

- 의존성 결정하기 : @Autowired
  생성자/필드/메서드 레벨에 인젝션
  파라미터 여러개 가진 메서드도 지원(간결하게..)
  기본적으로 autowire by type 실행
  autowiring을 좀더 유용하게 함

- @Qualifier 어노테이션
autowiring by type은 너무 많은 후보자를 가질수 있음
qualifier(제한하는 것)를 사용하여 힌트 제공 : 필드/파라미터/커스텀 어노테이션 위에 사용될 수 있음

- name에 의한 의존성 결정 : @Qualifier("myDataSource")
- 어노테이션에 의한 의존성 결정
public class JdbcOrderRepositoryImpl implements OrderRepository {
@Autowired
public void setOrderServices(
 @Emea OrderService emea,
 @Apac OrderService apac) {
 // ...
}
- 어노테이션으로 인젝션 타겟 연결
@Emea
public class EmeaOrderService implements OrderService {
...
}
@Apac
public class ApacOrderService implements OrderService {
...
}

@Qualifier
@Component
public @interface Emea {
}
@Qualifier
@Component
public @interface Apac{
}

- XML로 인젝션 타겟 연결
<bean class="example.EmeaOrderService">
<qualifier type=“example.Emea“/>
<!–
...
EmeaOrderService need not be annotated
-->
</bean>
<bean class="example.ApacOrderService">
<qualifier type=“example.Apac“/>
t h<i!s- -b eiannj e-c-t> any dependencies required by
</bean>

- @Autowired장점 : 간단, 간결, 하지만 여전히 강력한.. , 의존성 주입대상에게 스프링 종속적인 어노테이션을 강요하지 않음
- @Autowired단점 : injectees에게 스프링 종속적임(하지만 스프링에서 런타임 의존성은 없음)

- @Resource : 의존성 주입 포인트 표시, 하나의 컴포넌트에 표시, 스프링이 JNDI 참조를 투명하게 표시할 수 있다고 하더라도 컴포넌트가 JNDI로부터 와야한다고 강요하지 않음
- 장점 : Java EE 5 설정 형식 지원. 이식성 지원가능할수도...
- 단점 : 제한된 힘(@Resource 형식은 스프링 @Autowired 접근처럼 강력하지 않음, 오직 하나의 참조만 결정할 수 있고, qualifiers나 그 외 어노테이션 결정은 지원하지 않음)

JSR-250 라이프사이클 어노테이션
  - @PostConstruct : InitializingBean#afterPropertiesSet()과 비슷
  - @PreDestroy : DisposableBean#destroy()와 비슷
  스프링 종속적이지 않고, 간단하지만 표준화된 중요한 기능
  스프링 init-method나 InitializingBean 인터페이스의 위치에 이 어노테이션들을 사용하길 추천함

- @Component
     Meta-annotations : 확장성(자바 상속같은..), 다른 어노테이션을 어노테이트할 수 있음
     Spring stereotypes : 특정목적으로 클래스 정의할 수 있음. 어플리케이션의 강력한semantic모델 빌드하는데 도움. 스프링-종속적이지 않음. AspectJ pointcuts의 중요한 타겟.
- Out-of-the-box stereotype annotations
@Service : 무상태 서비스 정의
@Repository : DAO같은 레포지토리 정의
@Aspect : AspectJ 애스펙트
@Controller : MVC 콘트롤러
- can define your own annotations....with @Component

 - Component Scanning
annotated 클래스들의 클래스패스를 스캔
XML정의 할 필요없음(어노테이션으로 할 수 없는 걸 제외하고..)

- Component Scan Usage
스프링 코어의 context 네임스페이스 사용. 픽업할 패키지 구체화(base-package="")
XML빈설정과 양립할 수 있음
- More advanced component scanning usage
어노테이션에 국한되지 않고 type 이나 다른 체크도 사용할 수 있음
매우 커스터마이저블해서 어노테이션을 사용하지 않고서도 작동한다
  - 장점 : 허용하는 한에서 더 구체화시킬 필요없으면 굳이 XML이 필요치 않음. 자동으로 변화가 감지됨. 어노테이션 위주의 인젝션에 굉장히 잘 작동함.
  - 단점 : 모든 걸 다 할 수는 없다. 어노테이트될 클래스가 필요하다. 스프링 필터링 메카니즘을 사용하여 너무 과도한 클래스들이 스캔되지 않도록 주의할 필요가 있다. XML설정으로 가치있는 애플리케이션 스트럭쳐 블루프린트를 얻을 수 없다. (Spring IDE가 모든 스프링 컴포넌트 정의를 통합한다해도...)

- 믹스 앤 매치(XML or  Annotations)
결국 모두 스프링 메타데이타
스프링 컴포넌트 모델은 독립적인 메타데이타
어느 한 접근이 다른 식의 접근을 배척하지 않음
어느 한 컨텍스트에 다양한 기여를 할 수 있음

  - 명명관습
빈클래스의 짧은 이름으로 XML 빈 정의 제공
좀더 복잡한 시나리오에서는, @Component어노테이션에 "name"제공
  - 두 방식 복합
절대 헛되지 않아..
어느테이션의 한계에 부딪히면 강력하고 입증된 스프링XML모델을 사용할 수 있다.
(니가 한 걸 똑같이 다시 할 필요없이...)


- Spring MVC annotations
항상 유연한 모델 제공해 왔음
프레임웍의 어느 부분에서의 커스터마이징도 허용하는 확장포인트
HandlerMappings
HandlerAdapters
ViewResolvers

전형적인 활용에 의한 고착화된 상속과 관련된 단점
SimpleFormController와 수많은 템플릿 메서드를 포함한 다른 Base 클래스들

- Anotation-driven Controllers
  - MultiActionController 자바5로 진화(form 핸들링 능력을 갖춘...)
  - POJO기반 - 그냥 니 클래스 어노테이트해..서블릿컨테이너와 포틀릿 컨테이너에서 작동
  - 훌륭한 프로그래밍모델을 제공하는 어노테이션
    @Controller
    @RequestMapping
    @RequestMethod
    @RequestParam
    @ModelAttribute
    @SessionAttribute
    @InitBinder
- 개선된 어노테이션 기반 MVC
세션 어트리뷰트, 데이터 바인더 초기화, 폼 lifecycle을 위한 어노테이션

-스프링 포트폴리오(Enterprise Java의 요구사항에 맞춰 점점더 완벽한 솔루션을 제공하기 위해 스프링 프레임웍을 넘어 확장되고 있는...)
Spring Security 2.0
Spring Batch : SpringSource와 Accenture 공동개발
Spring Web Flow
Spring Web Services
Spring Integration
Spring Dynamic Modules for OSGi

- Spring Ecosystem
스프링 에코시스템은 상업적인 프로젝트와 그 외 오픈소스 프로젝트로 확장되고 있음
SpringSource Application Platform
WebLogic Server
WebLogic Event Server
Gigaspaces
SpringSource Tool Suite
SpringSource Advaned Management Suite(AMS)
SpringSource Advanced Pack for Oracle Database
...

- Spring 3.0
Spring MVC와 Spring Web Flow간에 통합된 프로그래밍 모델을 제시하여 웹프로그래밍계 전반적인 요구사항을 핸들할 수 있도록 할 것임
Spring MVC와 Spring Web Services를 통한 포괄적인 REST 지원

@출처 : JavaOne2008 Spring Framework 2.5 : New and Notable (by Rod Johnson)


덧글

댓글 입력 영역